genfscon and /boot

genfscon and /boot

[Russell Coker]

Currently the Red Hat kernels are compiled with Ext2 having no support for 
XATTR or ACLs.  This is convenient when dealing with boot loaders that don't 
support XATTR (such as the old Cobalt boot ROMs) as you can make /boot an 
ext2 file system and not risk making the machine unbootable.

The Sun/Cobalt people are aware of this issue and it will hopefully be 
resolved soon, but we still want a solution to this as probably not all 
hardware will get the bugs fixed soon enough.  Also some people who own 
Cobalt hardware may not desire a ROM upgrade.

Now for /boot to have appropriate labels we need genfs entries for it.  
Currently the genfs does not seem to support giving a different label to 
System.map* files (needed for ps to display the wchan and for kogd) and the 
other files (which need restricted access).  I tried the following genfs 
lines to no avail:

genfscon ext2 /                        system_u:object_r:boot_t
genfscon ext2 /System.map-             system_u:object_r:system_map_t

To get this working as desired we need to either change genfs to support 
appropriate labeling, or to change distributions to have System.map in 
another file system.  Having the System.map in a different file system may 
make sense anyway as we would probably prefer not to have /boot mounted in 
normal operation, but we do want to have System.map available all the time.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: genfscon and /boot

[Stephen Smalley]

On Thu, 2003-10-16 at 07:09, Russell Coker wrote:
> Currently the Red Hat kernels are compiled with Ext2 having no support for 
> XATTR or ACLs.  This is convenient when dealing with boot loaders that don't 
> support XATTR (such as the old Cobalt boot ROMs) as you can make /boot an 
> ext2 file system and not risk making the machine unbootable.
>
> The Sun/Cobalt people are aware of this issue and it will hopefully be 
> resolved soon, but we still want a solution to this as probably not all 
> hardware will get the bugs fixed soon enough.  Also some people who own 
> Cobalt hardware may not desire a ROM upgrade.

Supporting Cobalt hardware is not a priority for us, particularly not at
a sacrifice in security (which is what you are really suggesting).

> Now for /boot to have appropriate labels we need genfs entries for it.

genfscon cannot be used reliably for a filesystem type like ext2.
It works ok for proc, where we can reliably generate a pathname relative
to the root of proc from the proc_dir_entry tree, and is ok for mapping
all entries in certain filesystem types to a single fixed context, but
that is about it.  Pathname-based labeling doesn't work in Unix, much
less so in Linux.

> Currently the genfs does not seem to support giving a different label to 
> System.map* files (needed for ps to display the wchan and for kogd) and the 
> other files (which need restricted access).

The limitations of genfs_contexts are documented, both in the comments
at the beginning of genfs_contexts and in the PORTING file.  

> To get this working as desired we need to either change genfs to support 
> appropriate labeling, or to change distributions to have System.map in 
> another file system.  Having the System.map in a different file system may 
> make sense anyway as we would probably prefer not to have /boot mounted in 
> normal operation, but we do want to have System.map available all the time.

No, you just need to accept the fact that you need xattr support in the
kernel.

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: genfscon and /boot

[Russell Coker]

On Thu, 16 Oct 2003 22:55, Stephen Smalley wrote:
> Supporting Cobalt hardware is not a priority for us, particularly not at
> a sacrifice in security (which is what you are really suggesting).

I agree that we don't want to inconvenience ourselves for the benefit of 
Cobalt hardware, I am happy to maintain my own policy patches for that.  
However supporting the wider variety of systems which may have similar 
problems is desirable.  Otherwise we may just have a discussion like this 
every time someone ports to a new server platform, this includes rack mounted 
servers running LinuxBIOS, PDAs which have a Linux boot loader, and probably 
other things I haven't heard of.

Also this does not have to involve a sacrifice of security.  If we label 
everything under /boot with boot_t then the wchan option of ps is disabled, 
which is no great loss as 99.9% of all users don't know about it and most of 
the rest don't have any need for it.  Dumping a feature that's almost never 
used in favour of some functionality that has the potential to be a 
life-saver seems like a reasonable trade-off to me.

> > Now for /boot to have appropriate labels we need genfs entries for it.
>
> genfscon cannot be used reliably for a filesystem type like ext2.
> It works ok for proc, where we can reliably generate a pathname relative
> to the root of proc from the proc_dir_entry tree, and is ok for mapping
> all entries in certain filesystem types to a single fixed context, but
> that is about it.  Pathname-based labeling doesn't work in Unix, much
> less so in Linux.

OK.  Then how about an option to label all of /boot as boot_t?  There can be 
no confusion when all of a file system has the same label, and being overly 
restrictive should not be a problem.

Giving klogd access to boot_t should not be a great problem either, but it's 
also optional, klogd just misses some functionality in the case of an Oops if 
you don't give it access to System.map.

My only hesitation about this at the moment is that it makes things a little 
bit ugly in the policy.  Doing this requires changing the fs_use and 
genfs_contexts files as well as changing the type definition for boot_t.  
Having ifdef's in all these places in the policy will be annoying to manage, 
and naturally we want to have the default option to be using xattr's for 
ext2.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: genfscon and /boot

[Stephen Smalley]

On Thu, 2003-10-16 at 10:50, Russell Coker wrote:
> OK.  Then how about an option to label all of /boot as boot_t?  There can be 
> no confusion when all of a file system has the same label, and being overly 
> restrictive should not be a problem.

And we distinguish /boot from any other ext2 filesystem in what manner?
Particularly since any ext3 filesystem can also be mounted as an ext2
filesystem.

Exactly what is broken by having xattrs on /boot?  Why does this
interfere with the ability of old boot loaders to access /boot?

Of course, if we were still using the persistent label mapping, then
this wouldn't be an issue, but that wasn't an option...

-- 
Stephen Smalley <sds@epoch.ncsc.mil>
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: genfscon and /boot

[Russell Coker]

On Fri, 17 Oct 2003 01:01, Stephen Smalley wrote:
> On Thu, 2003-10-16 at 10:50, Russell Coker wrote:
> > OK.  Then how about an option to label all of /boot as boot_t?  There can
> > be no confusion when all of a file system has the same label, and being
> > overly restrictive should not be a problem.
>
> And we distinguish /boot from any other ext2 filesystem in what manner?

Yes, that is a problem.  However the number of other ext2 file systems is 
quite small.  The only ext2 file systems that I use are for /boot and for 
some old CDs (of course labeling CDs as boot_t would be annoying too).

Of course this can't be the default, but making it a readily accessible option 
seems to add value IMHO.

> Exactly what is broken by having xattrs on /boot?  Why does this
> interfere with the ability of old boot loaders to access /boot?

The kernel bug which prevents a 2.4 kernel without the XATTR patches from 
mounting a file system which has XATTRs affects all the boot loaders that are 
based on 2.4 kernel code.  AFAIK no-one is using a 2.6 kernel for a boot 
loader and Cobalt may be the first organization to apply XATTR patches to 
their 2.4 kernel based boot loader to fix this issue.

Given time all the boot loaders will be based on 2.6 kernels or newer 2.4 
kernels with this bug fixed.  In the mean time it is nice to be able to work 
around this.  For my personal use I have the choice between implementing this 
work-around, discarding two perfectly good servers, or waiting for Sun to 
release the new ROM.  I imagine that others will face a similar situation, 
and they may not have the same abilities to implement work-arounds and 
convince vendors to update their code as I do.

But I agree that this is a difficult issue, and I am not committed to getting 
it changed.

Finally the current plans (as I am aware of them) for Red Hat include having 
ext2 drivers compiled into the kernel without XATTR support for the initrd.  
Unless these plans are changed (which is another matter we should discuss 
now) then we will have some issues related to unlabeled ext2 file systems.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: genfscon and /boot

[Dale Amon]

On Thu, Oct 16, 2003 at 09:09:25PM +1000, Russell Coker wrote:
> The Sun/Cobalt people are aware of this issue and it will hopefully be 
> resolved soon, but we still want a solution to this as probably not all 
> hardware will get the bugs fixed soon enough.  Also some people who own 
> Cobalt hardware may not desire a ROM upgrade.

I haven't worked with one for two years, but I seem to remember
it is possible to upgrade the boot room yourself. Or it may be
a parity error in my memory banks... :-)


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: genfscon and /boot

[Russell Coker]

On Fri, 17 Oct 2003 02:02, Dale Amon wrote:
> On Thu, Oct 16, 2003 at 09:09:25PM +1000, Russell Coker wrote:
> > The Sun/Cobalt people are aware of this issue and it will hopefully be
> > resolved soon, but we still want a solution to this as probably not all
> > hardware will get the bugs fixed soon enough.  Also some people who own
> > Cobalt hardware may not desire a ROM upgrade.
>
> I haven't worked with one for two years, but I seem to remember
> it is possible to upgrade the boot room yourself. Or it may be
> a parity error in my memory banks... :-)

Yes, you can upgrade it yourself.  But keep in mind that an error or 
corruption will result in unusable hardware.  Such an upgrade makes ME 
nervous, many people will refuse to do such things to their hardware.  Also 
this is just one example of a problem situation where a work-around is 
desirable, there are others.

-- 
http://www.coker.com.au/selinux/   My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/  Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/    Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/  My home page


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.