Profile cover photo
Profile photo

Post has shared content

Post has shared content
Not pretty. However the bigger problem is not the obvious one. There will be patches very soon for all the usual Linux platforms (or roll your own RPM it's not hard). However guess what many of those cheap GPL violating no source code ADSL routers that never get firmware upgrades run for their own internal use and to masquerade DNS.

Oh dear..

And that is why source code to your infrastructure is so important. This bug just obsoleted a pile of low end crapware router and firewall boxes holding homes, businesses and government together.

You can upgrade all your servers but if that little cheapo plastic box on your network somewhere has a vulnerable post 2008 glibc and ever does DNS lookups chances are it's the equivalent of a trapdoor into your network.

Even more fun of course - some of them regularly do poll some hardcoded DNS address so if anyone takes over that DNS record and starts serving a suitably compromised record back ...

Post has shared content
+Lennart Poettering just posted the 21st part of the systemd For Administrator series, this time covering container integration. Enjoy!

Post has shared content
More people have been asking me when this would be submitted, than any other bit of kernel code I have ever worked on.

The wait is now over.

Post has attachment

Post has shared content
Seems the Skype team over at Microsoft have released a new version and are dropping support for non-PulseAudio setups on Linux.

Post has shared content
Originally shared by ****
Minimal Fedora installation with:
  $ rm -rf /etc/* /var/*

The first boot with an empty /etc will trigger this:
  Initializing machine ID from random generator.
  Starting Create System Users...
  Starting Rebuild Hardware Database...
  Starting Rebuild Dynamic Linker Cache...
  Starting Rebuild Journal Catalog...

"Broken" facilities regarding files in /etc are: pam, pki, yum; they need to be re-created from /usr/share/factory/etc/ at the first bootstrap boot. Details are in the script.

Post has shared content
Originally shared by ****
systemd-nspawn sucessfully booting a rootfs directory containing nothing but a /usr directory:

  # mkdir /tmp/newsystem
  # cp -ax /usr /tmp/newsystem
  # ./systemd-nspawn -b -D /tmp/newsystem
  Spawning container newsystem on /tmp/newsystem.

For everybody who was questioning why we needed to move /bin, /sbin, /lib, /lib64 to /usr instead of spreading the installed operating system over many directories, here is your use case.

PAM, yum, pki, dbus-1 are still broken regarding the "empty /etc model", and need to be fixed.

Post has shared content
I just added two new service sandboxing features to +systemd: the ReadOnlySystem= and ProtectedHome= settings for services. The former mounts /usr and /boot read-only for the specific service, the latter mounts /home and /run/user either read-only or replaces it with an empty, inaccessible directory. With these easy options we hence can make sure now that specific services don't get the chance to modify the operating system itself, or to get access to the user's personal data.

I have also now enabled this functionality for all of systemd's own long-running services. Of course, ideally we get all of Fedora to enable these settings for all long-running services. This should improve our security quite a bit by default, in particular for network-facing services.

Of course, if you know systemd well you know that something like this was already possible with appropriate settings for ReadOnlyDirectores= and InaccessibleDirectories=. Internally, these options build on the same mechanisms, however, our intention here is to make these simple booleans, so that they can be one-stop, simple solutions to making the system more secure.

And yupp, of course, if your daemon retains CAP_SYS_ADMIN then it can undo the effect, so best is to combine these settings with CapabilityBoundingSet=~CAP_SYS_ADMIN. But even without that these settings should be an improvement.

This of course works on top of other ways to protect the OS and user data, for example on top of classic UNIX access controls or SELinux. While these mostly focus on individual files and fine-grained access control to them, with pretty big holes for the root user, our new settings are very simple, broad lever that even affect the root user fully (well, modulo the CAP_SYS_ADMIN thing)...

Post has shared content
Wait while more posts are being loaded