Ownership of kernel headers

Matthias Benkmann matthias at winterdrache.de
Mon Oct 14 00:50:56 PDT 2002


On Sun, 13 Oct 2002 19:00:55 -0400 Zack Winkles <sativa93 at bellsouth.net>
wrote:

> > Oops. I should have noticed myself. You got a point here. This is not
> > only an issue with the kernel but some other packages as well.
> > However, changing ownership after untarring is not a good solution
> > because there is enough time for an attacker to replace files before
> > ownership is changed. As a security measure, we could chmod go-x /lfs.
> > 
> > MSB
> > 
> 
> I guess I just wasn't clear on what I meant. 

Why do you think so? Once you replaced chapter 5 with chapter 6 I
understood you perfectly.

> the entire system or any after-LFS stuff. I'm just saying that when we 
> extract the kernel in chapter 6 is leaves an open door because after 
> the installation the kernel source code is still owned by uid 537 (or 
> something like that). 

I understand what you're saying but it's not correct. cp does not preserve
ownership by default. The kernel headers on my new system are owned by
root and I didn't chown them. If they are not owned by root on your system
you probably used a different command (cp -a for instance) to copy.
But this does not mean there is no problem. There IS a problem (see below)

>but if the 
> system were to have a user who gets assigned that UID then the next 
> kernel compile may have some 'surprises' in store...

Someone might already have said user id on the host system! This means
that if you're building your LFS on a machine used by others, you may be
vulnerable to attacks. What makes matters worse is that the building of an
LFS system takes a long time, and is very obvious to any observer on the
system. Because the steps used to build an LFS system are predefined and
the user ids of all packages are known to the attacker, the attacker can
just wait till you have reached the appropriate point in the book.
Extracting a tarball takes a while. An automated script that watches a
directory and replaces a file once tar has created it is easy to write.
The times we're dealing here are in the seconds range, so unlike the
mktemp() attack this one does not rely on scheduler timing.
And in case I've not made this clear enough. The vulnerable point is
already the extraction of the tarball. The very moment that you press
enter after tar xzf foo.tar.gz, you are vulnerable if you act as root,
because then tar extracts ownership (and there seems to be no way to
prevent this).
A suitable defense is the suggested chmod go-x $LFS.
 
MSB

-- 
I used to have an open mind but my brains kept falling out.

-- 
Unsubscribe: send email to listar at linuxfromscratch.org
and put 'unsubscribe lfs-dev' in the subject header of the message



More information about the lfs-dev mailing list