Ubuntu LTS: many vulnerabilities despite long-term support

I'm going to try it on Ubuntu tonight

 

I think the only distro (that I've tested) that is VERY DEEPLY entantled with geoclue is Arch, which is odd given how minimalistic the distro is in most aspects. In order to use MATE in Arch you need to install webkitgtk, and Arch developers make 'gst-plugins-bad' and 'geoclue' as hard dependencies, and if you simply try to remove them you'll remove everthing (like MATE). And trust me, it takes forever to build webkitgtk, so it's much easier to create dummy packages.

Good luck. I hope you have a fast processor, because unfortunately there's no grsec repo for Ubuntu, so you must build the Kernel yourself. Do you need instructions on how to do so?

Don't forget to install checksec, pax-utils, paxctl, paxctld, and paxtest. I think they're all on Ubuntu's default repo, so you really only need to build the Kernel image.

 

I use the script to build the kernel. It takes maybe an hour I go get something to eat then come back to the pc and reboot. Installs the kernel, installs the test patch, you make file reboot and done. I've never tried it on Ubuntu but having another layer of security in AppArmor will be worth some headaches though if I get stuck I'll take you up on your offer.

I use InsanityBits grsec options. I see checksec hasn't been updated since 2011 so I am a little hesitant to install it.

 

@AutoCascade Do you mind showing what is this script? I'm very interested to know.

 

I use this basically because I have trouble doing it manually.

https://github.com/rickard2/grsecurity-Debian-Installer

 

Does it work fine with Ubuntu? Even nowadays?

 

I will be trying later today or tomorrow. I had some Family stop by earlier tonight so I haven't tried yet.

It works with Mint. It worked with Mint LMDE. I've installed Debian a couple of times and I've hit my head against the wall a few times because it doesn't support my graphics card so I never got far enough iwith it.

 

Why don't you try the Debian grsecurity kernel? Should be easier than compiling it yourself, and it should work with Ubuntu.

 

That's only available for SID or have they already made it to Jessie stable? I actually was just looking at the unstable debian grsec kernel since it's a .deb file I can just dpkg -i ./<name.of.deb> after creating a directory for it?

The script wouldn't even run on Ubuntu, I tried it a couple of times.

 

I'm going to just stay on 4.4.8 for now. I have the latest test patch.

There was quite a dust up on Twitter and Grsec pulled their account and wiped out their archive of posts. Big thread on Reddit and some stories online about it. I follow him on Twitter or I use to follow him. He tweeted that new test patches would only be announced through their RSS feed which I can't find.

 

So? As mentioned it should work on Ubuntu, at least it's worth a try.

 

@AutoCascade
@summerheat

Rule of thumb: Never, EVER, mix Debian and Ubuntu. NEVER. You shouldn't even Mix Debian Stable with other releases of Debian. Don't use PPA's on Debian, don't use Debian packages on Ubuntu, and don't use packages for Ubuntu on Debian. And don't use Sid/Testing packages on Stable, use Backports instead (which is risky, but not as risky as using Sid/Testing programs directly on Jessie).

@AutoCascade Jessie already has a repo maintained by the same developer who maintains the grsec packages on Sid/Jessie.

 

Unfortunately for Ubuntu you'll have to compile the Kernel manually. There are a lot of tutorials, though, so it shouldn't be hard.

I had a dream the other day with Mark Shuttleworth. He said grsec will be present on Ubuntu in a package format

 

That's not a must. There are many .deb packages out there which are identical for Debian and Ubuntu (example: Firejail). And the kernel is usually the stock kernel with some modifications in config.

This is normally because of different dependencies and different library versions. But again, a Debian kernel should work on Ubuntu. Anyways, it would be installed alongside the Ubuntu kernel so it's always possible to go back to it if problems arise.

 

Ubuntu and Debian differ a lot when it comes to libraries and dependencies. Although Ubuntu picks it's packages from Debian Unstable, the LTS releases will fall behind eventually, and so will the non-LTS releases (because they're basically a "frozen debian sid"), so what worked at the time of launch will likely bork the entire system if used later on Ubuntu or even un-updated Debian Testing/Sid.

Then there's the dependency chain, folder and file structure, configuration files that are distro specific, "hacks" that won't work on other distros, and etc.

Ask any Debian developer, "what happens when mixing packages and distributions" ;-) It's a road to disaster. There are tons of threads of people who rendered their system unusable because they were stubborn (and they deserve it). A simple search reveals htousands of them.

Even backported packages, which come from official Debian developers, can break the Stable release, and they (should) know what they're doing.

Ubuntu and Debian Kernels are not even close to vanilla Kernel from kernel.org, they both have patches and modifications (just look at their source files) that are not present in the vanilla kernel.

The safest way to install/patch the Kernel on Ubuntu is to get the sources of the Ubuntu Kernel (with all the patches) and grsec, patch everything like Canonical does, then patch with grsec, then make the configuration accordingly (.conf is a nice place, with a text editor, just place the grsec config part from the Debian sources), then compile the Kernel.

You can compile vanilla Kernel from kernel.org and not patch it like Ubuntu and Debian do, but you MUST read the source files of your distro Kernel to see if you need those patches, otherwise your Kernel (and therefore the OS) can operate in a broken state (the patches exist for a reason).

 

I would bet anyone using this Distro, who's completely oblivious to its "many vulnerabilities" will simply enjoy using it and never once fall victim to malware. Sometimes ignorance is bliss.

 

Yeah I actually downloaded the SID grsec kernel as a .deb package which should make it a lot easier to install. I've just had a brutal day work wise so I'm just staying with what I've got for now but the .deb kernel will stay on my mind.

 

I'm afraid we're getting OT here, but some remarks nonetheless.

I didn't deny that. It's always highly recommended to only use the packages from the proper repos. However, it really depends on which dependencies and (versions of) libraries a package needs. An example already mentioned is Firejail, other examples are Google Chrome, LibreOffice (if you download it from their homepage) and Ungoogled Chromium. All those programmes have one .deb package both for Debian and Ubuntu. So again, it really depends.

This is in many cases not as problematic as you suggest. Ubuntu has been offering unmodified upstream kernels for years. Whenever I had used them in the past I hadn't run into problems. Yes, there might be specific settings in .config (e.g. CONFIG_SECURITY_APPARMOR is not set in the Arch kernel), but in most cases they don't cause problems, either. Remember how many kernel variants with different .config files are offered for Arch Linux. There are already several of them in the official repos and umpteen more in the AUR. Granted, there is no guaranty that the Debian grsec kernel works flawlessly on Ubuntu - that's why I said that it should work. If really problems come up it's easy to revert to the Ubuntu kernel so it's worth a try.

But again, we're getting OT here. This thread is not about missing grsec kernels in Ubuntu but about the promise to deliver security updates for 5 years - a promise that isn't fulfilled for many packages in universe.

 

Firejail ships it's own libraries, Libreoffice does this as well but puts it's files into /opt, which is the location for "the installation of add-on application software packages". /opt is used for local libraries/binaries, not system-wide ones I'm pretty sure the others do this as well, but I haven't tested them.

As long as the program doesn't require a crazy version of e.g. libc6 (which happens on LTS and Stable releases of Debian and Ubuntu), it's fine.

However, look at what happened when Steam was released for Linux: Debian Stable was called Wheezy and it didn't have the required libc6 for Steam. (Libc6 is one of the fundamental libraries in Linux). People then installed libc6 from Jessie. Result: A ton of borked systems. I know, I did it myself

Exactly what I said He might not run into problems, but he could as well do. The patches are there for a reason: people have problems with Kernels, and so distros patch them while upstream doesn 't(kernel.org). That's why I said to read the patches to see if they actually bring something useful to the user. If not, then there's no problem in using upstream Kernels.

I honestly didn't look at the source files for them, but I imagine they don't differ too much because they're tested to work with Arch. Sometimes different patches/configs are needed for different Kernels such as linux, linux-lts, linux-zen, etc.

But that is not an official part of Arch, it's a place where users submit their own packages.

Sure I don't remember saying "it shouldn't work", but if I did then my apologies. It could work, but I'm only expressing my concerns in regards to compatibility between both. I'm anxious to see if it works, though

Agreed. Let's get back on topic

 

Just 1 more example for universe packages with security leaks which are not fixed in Ubuntu:

Imagemagick: A new vulnerabilty was published although an old vulnerability in this package isn't fixed in Ubuntu yet. It probably affects mostly servers where users can upload images (like forum avatars) but it's also used by many other packages (like calibre) so desktop users are also affected. It's fixed in Debian but not in Ubuntu although the vulnerability was reported nearly 1 month ago.

 

Imagemagick - fixed in CentOS 7. Workaround in summerheats 'vulnerability' link.
Oops, only for the old vulnerability.

 

Somehow ubuntu has managed to get much more widespread than debian yet I think debian is much superior in terms of the way they support the system and flexibility.

 

debian builds packages in same way

root@hdd-nl2 www # hardening-check /usr/sbin/sshd
/usr/sbin/sshd:
Position Independent Executable: yes
Stack protected: yes
Fortify Source functions: yes (some protected functions found)
Read-only relocations: yes
Immediate binding: yes

https://wiki.debian.org/Hardening

By the way for the curious the grsec kernel can cause massive slowdowns on non accelerated cpu's, on this box with a nano cpu it was taking 3 secs to load nano text editor on the prebuilt grsec kernel and some functions are extremely slow, e.g. installing a new kernel took nearly 3 hours when running under grsec, whilst on a normal kernel its about 40 seconds.

I plan to do more testing but on a custom grsec kernel with some things disabled.

 

There's a trade between Ubuntu and Debian. One offers a more easy to use system. The other offers better security.

 

yes, seems most have opted for the ease of use.