5:14 p.m.
Kyle,
From latest Rawhide kernel.rpm:
* Wed Nov 17 2010 Kyle McMartin <kyle(a)redhat.com>
- Make vmlinuz/System.map root read-write only by default. You can
just chmod 644 them later if you (unlikely) need them without root.
This completely breaks libguestfs. We need to be able to read the
kernel image in order to boot it in qemu as a non-root user.
What's the motivation for this change?
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://et.redhat.com/~rjones/libguestfs/
See what it can do: http://et.redhat.com/~rjones/libguestfs/recipes.html
3:15 p.m.
On Fri, Nov 19, 2010 at 11:14:39PM +0000, Richard W.M. Jones wrote:
Kyle,
From latest Rawhide kernel.rpm:
* Wed Nov 17 2010 Kyle McMartin <kyle(a)redhat.com>
- Make vmlinuz/System.map root read-write only by default. You can
just chmod 644 them later if you (unlikely) need them without root.
This completely breaks libguestfs. We need to be able to read the
kernel image in order to boot it in qemu as a non-root user.
What's the motivation for this change?
Preventing rootkits from being able to trivially find addresses.
5:01 p.m.
On Sat, Nov 20, 2010 at 04:15:51PM -0500, Kyle McMartin wrote:
On Fri, Nov 19, 2010 at 11:14:39PM +0000, Richard W.M. Jones wrote:
> Kyle,
>
> From latest Rawhide kernel.rpm:
>
> * Wed Nov 17 2010 Kyle McMartin <kyle(a)redhat.com>
> - Make vmlinuz/System.map root read-write only by default. You can
> just chmod 644 them later if you (unlikely) need them without root.
>
> This completely breaks libguestfs. We need to be able to read the
> kernel image in order to boot it in qemu as a non-root user.
>
> What's the motivation for this change?
Preventing rootkits from being able to trivially find addresses.
Thank you, I found the LKML thread in the end:
http://lwn.net/SubscriberLink/415603/d963e2f5078ba880/
The thing is, we really need to be able to boot a kernel in qemu as
non-root, and carrying around a separately compiled or packaged kernel
is in nobody's interest.
I'm fairly sure this won't be the only application to break. We found
it first because we are compiling and booting Rawhide in qemu
virtually daily (so we tend to find any kernel or qemu problems very
quickly -- it's the bain of my life). But I bet others will be
needing to read those files.
Also, I do think this smacks a bit of security through obscurity ..
after all, the files that are being 'protected' here are being carried
on a hundred or more mirror sites. It's the worst-kept secret :-)
In the worst case all an attacker needs to do is to carry around a map
of kernel version -> symbol address. At best if they can inject a
little bit of shell code into the kernel, it's easy to search for the
symbol table and from there to get to any symbol they need (some time
ago I wrote some code to do exactly this[1]).
Avi suggested on LKML that the kernel could be relocated to a random
address at boot. Sounds like a better idea to me if that would work.
Rich.
[1] http://git.annexia.org/?p=virt-mem.git;a=tree;f=lib;hb=HEAD
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
New in Fedora 11: Fedora Windows cross-compiler. Compile Windows
programs, test, and build Windows installers. Over 70 libraries supprt'd
http://fedoraproject.org/wiki/MinGW http://www.annexia.org/fedora_mingw
9:41 p.m.
Richard W.M. Jones wrote:
The thing is, we really need to be able to boot a kernel in qemu as
non-root, and carrying around a separately compiled or packaged kernel
is in nobody's interest.
I'm fairly sure this won't be the only application to break. We found
it first because we are compiling and booting Rawhide in qemu
virtually daily (so we tend to find any kernel or qemu problems very
quickly -- it's the bain of my life). But I bet others will be
needing to read those files.
Also, I do think this smacks a bit of security through obscurity ..
after all, the files that are being 'protected' here are being carried
on a hundred or more mirror sites. It's the worst-kept secret :-)
Uhm, indeed, making publicly available files non-readable is really useless.
Kevin Kofler
9:45 p.m.
On Sun, Nov 21, 2010 at 04:41:47AM +0100, Kevin Kofler wrote:
Richard W.M. Jones wrote:
> The thing is, we really need to be able to boot a kernel in qemu as
> non-root, and carrying around a separately compiled or packaged kernel
> is in nobody's interest.
>
> I'm fairly sure this won't be the only application to break. We found
> it first because we are compiling and booting Rawhide in qemu
> virtually daily (so we tend to find any kernel or qemu problems very
> quickly -- it's the bain of my life). But I bet others will be
> needing to read those files.
>
> Also, I do think this smacks a bit of security through obscurity ..
> after all, the files that are being 'protected' here are being carried
> on a hundred or more mirror sites. It's the worst-kept secret :-)
Uhm, indeed, making publicly available files non-readable is really useless.
If it stops even one automated attack, then it's worth while.
10:28 p.m.
Kyle McMartin <kyle(a)mcmartin.ca> writes:
On Sun, Nov 21, 2010 at 04:41:47AM +0100, Kevin Kofler wrote:
> Uhm, indeed, making publicly available files non-readable is really useless.
If it stops even one automated attack, then it's worth while.
That's completely ridiculous. Shutting down Fedora altogether would
stop quite a lot of automated attacks, but we're not gonna do that.
What has to be asked is how much protection do you get for how much
loss of functionality; and from what I can gather on this thread,
this change doesn't look very good on that tradeoff scale.
Absolutism is not a useful approach to security.
regards, tom lane
9:34 a.m.
On Sat, 2010-11-20 at 22:45 -0500, Kyle McMartin wrote:
On Sun, Nov 21, 2010 at 04:41:47AM +0100, Kevin Kofler wrote:
> Richard W.M. Jones wrote:
> > The thing is, we really need to be able to boot a kernel in qemu as
> > non-root, and carrying around a separately compiled or packaged kernel
> > is in nobody's interest.
> >
> > I'm fairly sure this won't be the only application to break. We found
> > it first because we are compiling and booting Rawhide in qemu
> > virtually daily (so we tend to find any kernel or qemu problems very
> > quickly -- it's the bain of my life). But I bet others will be
> > needing to read those files.
> >
> > Also, I do think this smacks a bit of security through obscurity ..
> > after all, the files that are being 'protected' here are being carried
> > on a hundred or more mirror sites. It's the worst-kept secret :-)
>
> Uhm, indeed, making publicly available files non-readable is really useless.
>
If it stops even one automated attack, then it's worth while.
Is it going to stop an automated attach? If it's automated, it'll just
get the uts name, then pull the files from some website, or probably
come packed with the known addresses for various kernels (which of the
ones I've seen in the wild for former exploits seems to be what is done
- they don't read these files from the local filesystem). Not sure it's
worth getting all TSA-y on this :)
Jon.
4943
days inactive
4947
days old
6 comments
5 participants
participants (5)
-
Jon Masters -
Kevin Kofler -
Kyle McMartin -
Richard W.M. Jones -
Tom Lane