Home Home
Sign up | Login

Author Archive

Next: openSUSE hardening

September 15th, 2014 by

Now.

Running the rolling openSUSE Factory has been smooth so far, no problems since the last post.

I have been involved in submitting new packages (ftop, dstat, some perl modules), patching other’s existing packages (dnsmasq) and of course taking after packages that I maintain (btrfsprogs). With a very few exceptions I’ve got done everything I needed, the exceptions were my rather silly mistakes. The damage is only the first few seconds when one realizes that the submit request was ‘rejected’. Don’t get bored by it, grab a coffee or go fix it later. Need to say the rejects are backed by a reason or explanation what’s wrong and what should be fixed in the next attempt. Learn from that, take notes, read the docs again. Once this becomes common, the amount of basic mistakes is near to zero, the self-checks become a routine. This makes a happy contributor and the distro maintainers too.

I recommend to skim the factory snapshots announcements, look at the changes or scroll down to the newly added ones. One day you can see your contributions there, go for it.

Before something goes to the Factory distro, the packages are getting ready in the devel projects. I’ve asked for maintainership of filesystems and benchmark projects and did some fixing in packages I use or at least recognize. The state of the projects is not ‘all-green’, build failures exist, but without some motivation I’m not rushing to fix them.

If you are interested (as a user) in a package from those devel projects, feel free to bug me about it. I can help with fixing build failures or submitting to Factory.

Next?

All of the above is a routine. A routine of making the distro better on the core side. There’s never enough of it and it may become boring (oh it does) over time. Out of the many research projects and experimenting I do, I decided to focus on one that’s definetely related to openSUSE, is fun, is important, useful and is not there yet.

openSUSE hardening!

“No way, really? But there’s AppArmor and SElinux enabled and the compile-time hardening options.

Yeah. I won’t repeat the arguments why AppArmor and SElinux are insufficient, functionally or usability-wise. So what’s left? Grsecurity, of course. Sadly openSUSE lacks even the unofficial grsecurity-patched kernels unlike Arch, Debian or Gentoo. Sadly2, the patched kernels are unofficial and will remain at that state until grsec is upstream. I don’t dare to predict if/when this will happen.

I’m aware of only the NetSecL distribution based on openSUSE that offered the grsec kernels, but it’s discontinued.

My hardening efforts got the codename openSUSE-gardening and are hosted in my github repository of the same name. The wiki contains more comprehensive information. It’s still work in progress and does not cover all topics in detail but should be enough to get started.

Quite unexpectedly, spender found the repo and gave it a bit of publicity on twitter. Thanks man 🙂

My plan was to update all relevant packages, test the kernels a bit, update the wiki and then post about that here. Nah, I got the right kick to do it now.

Quick start is really simple, a pattern that installs all necessary packages for a desktop use:

One-click install for 13.1
One-click install for Factory

Note, you’ll probably need to run linux-pax-flags before the first reboot, it will apply PaX flag exceptions, some binaries may crash due to the protections (like window manager processes, browsers). Once the zypper plugin is properly installed, the flags get updated automatically.

Warning: the patched kernel has not been extensively tested, works for me, might not work for you.

To be continued …

Going Factorial

August 22nd, 2014 by

After the unclear status of openSUSE direction, the news about creating a rolling distro was a surprise, but a good one. The revised development model of Factory looks better and though it’s too early to make conclusions, works for me. The transition was straightforward, following the wiki recommendations and simply pointing all repository URLs from 13.1, verifying the proposed changes.

I’m not using a clean 13.1 installation, but a mixture of base distro packages, Tumbleweed, Kernel:stable, packman, and a few devel projects. This requires careful setting of repository prorities and reviewing each zypper dup round, I’m certainly not recommending this to inexperienced users.

Besides the OBS-provided projects, I’ve been maintaining a few packages in my home project. I admit that the right way is to submit the packages to the distro, but laziness and lack of time to the rescue.

The release cycle of openSUSE suits better users that do not tweak their systems too often and expect it to just work. But there are developers who need newer version, or users who simply want to install newer versions. This is where Tumbleweed fills the gap.

One of the visible differences between Tumbleweed and the rolling Factory is number of packages. Due to a small number of packages maintained in my home project, I did not bother submitting them to Tumbleweed. Also because they do not fit very well to its intended package selection. This comprises benchmarking tools or some tweaks and experiments with random packages.

With the announcement of rolling Factory, I’ve decided to clean up all my local changes and forward them to Factory projects. This also ended the period where openSUSE was did not have a clear direction, based on my observations. And I like the new direction, I do want to use a rolling distro, and I’m going to spend more time on updating packages I use. Let’s get rolling!