What is being protected by this mode change? This kernel is distributed
on hundreds of mirrors -- there is no secret in here.

When we install libguestfs, we need to boot using this kernel. What change
do I need to make to libguestfs so that when a sysadmin installs it, it will
change the permissions back to 0644 automatically?

On Tue, Apr 26, 2011 at 11:21:38AM -0000, Richard W.M. Jones wrote:
> What is being protected by this mode change? This kernel is distributed
> on hundreds of mirrors -- there is no secret in here.

The mode changes do not protect a system from any dedicated attacker (for
the reason you state), but it does have real-world benefits against
simplistic kernel exploitation (keeping kernel symbols away from non-root
users). It is absolutely a trade-off.

> When we install libguestfs, we need to boot using this kernel. What change
> do I need to make to libguestfs so that when a sysadmin installs it, it will
> change the permissions back to 0644 automatically?

Shipping a pair of files in /etc/kernel/postinst.d/ and
/etc/kernel/postrm.d/ to call dpkg-statoverride --add and --remove
respectively is likely the cleanest approach to handling this.

On Tue, Apr 26, 2011 at 05:25:33PM -0000, Kees Cook wrote:
> On Tue, Apr 26, 2011 at 11:21:38AM -0000, Richard W.M. Jones wrote:
> > What is being protected by this mode change? This kernel is distributed
> > on hundreds of mirrors -- there is no secret in here.
>
> The mode changes do not protect a system from any dedicated attacker (for
> the reason you state), but it does have real-world benefits against
> simplistic kernel exploitation (keeping kernel symbols away from non-root
> users). It is absolutely a trade-off.

This non-root user that we imagine has no access to the world
wide web? This is absolutely nuts, sorry.

By the way, I myself actually wrote code that walks through the kernel memory
finding the location of the symbols. You're not gaining any extra security by
making this change, but you are making Ubuntu less useful.

I recognize this can get in some people's way, which is why I've tried to demonstrate how to adjust the local system to retain the more open permissions.

I am not saying they're hidden from being looked up externally (just fetching the kernel package's System.map file is easiest). But because the symbols can be extracted in the way you point out is why the kernel image itself needs to be unreadable. This change is to block the class of attacks carried out by script kiddies and automated systems that expect to be able to look up symbols locally and make exploits totally portable to all kernel versions. It changes the nature of future attacks, at least forcing attackers to take additional steps.

The postinst.d and prerm.d solution should provide a reasonable work-around for the small number of systems that need it.

On Tue, Apr 26, 2011 at 09:49:25PM -0000, Kees Cook wrote:
> But because the symbols can be extracted in the way you point out is
> why the kernel image itself needs to be unreadable. This change is
> to block the class of attacks carried out by script kiddies and
> automated systems that expect to be able to look up symbols locally
> and make exploits totally portable to all kernel versions.

You didn't appear to understand the code that I wrote: it gets out the
symbols from any version of the kernel by simply reading the kernel
*runtime memory*.

So the attacker now has two alternative methods: (a) fire up a web
browser or (b) inject shell code into the kernel which greps through
physical memory to find the symbol tables, and note method (b) works
with any kernel version without reference to the original vmlinuz
file.

> It changes the nature of future attacks, at least forcing attackers
> to take additional steps.

Yes, firing up a web browser or injecting an extra small piece of
shell code into the kernel.

I need to mount a binary file that contains a filesystem so I can copy files onto it.

I could already do this using /dev/loop but I need to automate this without requiring root privileges for a build system.

To solve this problem, the guestmount folks pulled together TONS of code. They are creating a custom minimized kernel, emulating it with QEMU, booting it with the binary file attached, attaching FUSE to the mount point and connecting to it at the application layer. All to avoid needing /dev/loop and root access.

Guestmount used to work out of the box. And you just broke it "by-design" with a change that provides zero security or protection from anyone with a brain or an internet connection. I agree with Rich W. M. Jones. You are making ubuntu less useful.

This also affects monitoring tools like e.g. the libs test in hobbit-plugins which compare the running kernel version to the one on disk. These tests don't run as root as they don't need to. Now they need elevated privileges just do this check... :-/

Is it possible to change vmlinuz permissions so it's readable by members of special group (libguestfs)?.
This way admins could locally fix this "by design" stupidity easily for affected users instead of forcing maintainers for all the affected packages to supply statoverride scripts.

This works only if started the ./libs localy, but not via xymonclient. There I got the error "sudo: no tty present and no askpass program specified", but I don't know how to adapt it, that it works also with the xymonclient.