up2date, Large Medium and small updates....

[Tom Mitchell]

Today up2date found a very long list of package updates
on rawhide 500+ for me.

Since the box is a test box ... I let it.

I am curious if labels/attributes on all the new files
will be correct for SELinux after this and other up2date (rpm)
actions (excluding changes  to /etc/security/selinux/src/policy/....).

The more general question is that for  Large Medium and small updates....
there may always be a question when one or more "makes" in the policy
area will be needed.  Is there a good way to check... will make
check-all do the right thing?

   cd /etc/security/selinux/src/policy
   make ?????  # lots of choices...
   make relabel  # necessary? when and how to check ...

Is it necessary/useful to do stuff like this before or after a reboot?
Is there a difference from vanilla in how promptly a reboot and other
housecleaning for SELinux is needed?  i.e. will audit go nuts...

Also I have taken to adding an alternate boot section  in
/boot/grub/grub.conf.  Is this useful, useless, sane, silly,
underkill, overkill.  Thus...:

 title Fedora Core (2.6.3-2.1.246)
        root (hd0,0)
        kernel /vmlinuz-2.6.3-2.1.246 ro root=LABEL=/ 
        initrd /initrd-2.6.3-2.1.246.img
 title Fedora Core NoSELinux (2.6.3-2.1.246)
        root (hd0,0)
        kernel /vmlinuz-2.6.3-2.1.246 ro root=LABEL=/ selinux=0 
        initrd /initrd-2.6.3-2.1.246.img


Hmmm... too many questions for one subject line...




-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.
	mitch48-at-sbcglobal-dot-net

[Russell Coker]

On Wed, 10 Mar 2004 12:40, Tom Mitchell <mitch48(a)yahoo.com&gt; wrote:
>  The more general question is that for  Large Medium and small
> updates....
>  there may always be a question when one or more "makes" in the policy
>  area will be needed.  Is there a good way to check... will make
>  check-all do the right thing?
>
>     cd /etc/security/selinux/src/policy
>     make ?????  # lots of choices...
>     make relabel  # necessary? when and how to check ...
>
>  Is it necessary/useful to do stuff like this before or after a reboot?
>  Is there a difference from vanilla in how promptly a reboot and other
>  housecleaning for SELinux is needed?  i.e. will audit go nuts... 
In general use there should not be any need for a relabel except after severe 
file system corruption, a backup/restore with non-XATTR aware backup 
software, or booting a non-SE Linux kernel.

>  Also I have taken to adding an alternate boot section  in
>  /boot/grub/grub.conf.  Is this useful, useless, sane, silly,
>  underkill, overkill.  Thus...: 
Grub is really good for allowing you to edit the kernel command line before 
booting it.  So if you have problems you can always tell it to boot the 
kernel with selinux=0 appended even if that is not in your grub.conf.

If you accidentally boot a non-SE kernel then /etc/mtab and a few other files 
will get the wrong label, which will be really annoying for you.  We are 
working on these issues, but in the mean-time you probably don't want to make 
it too easy to accidentally boot a non-SE kernel.

-- 
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

[Richard Hally]

Fwiw, in grub I set up duplicate sections for a permissive kernel and an
enforcing kernel using ENFORCING on the title line and enforcing=1 on the
kernel line.

Richard Hally

<Snip>
>  Also I have taken to adding an alternate boot section  in
>  /boot/grub/grub.conf.  Is this useful, useless, sane, silly,
>  underkill, overkill.  Thus...: 
Grub is really good for allowing you to edit the kernel command line before
booting it.  So if you have problems you can always tell it to boot the
kernel with selinux=0 appended even if that is not in your grub.conf.

If you accidentally boot a non-SE kernel then /etc/mtab and a few other
files
will get the wrong label, which will be really annoying for you.  We are
working on these issues, but in the mean-time you probably don't want to
make
it too easy to accidentally boot a non-SE kernel.

[Tom Mitchell]

On Wed, Mar 10, 2004 at 03:27:52AM -0500, Richard Hally wrote:

>  Fwiw, in grub I set up duplicate sections for a permissive kernel and
> an
>  enforcing kernel using ENFORCING on the title line and enforcing=1 on the
>  kernel line.
>  
>  Richard Hally
>  
>  <Snip>
>  > Also I have taken to adding an alternate boot section  in
>  > /boot/grub/grub.conf.  Is this useful, useless, sane, silly,
>  > underkill, overkill.  Thus...:
>  
>  Grub is really good for allowing you to edit the kernel command line before
>  booting it.  So if you have problems you can always tell it to boot the
>  kernel with selinux=0 appended even if that is not in your grub.conf.
>  
>  If you accidentally boot a non-SE kernel then /etc/mtab and a few other
>  files  will get the wrong label, which will be really annoying for you.  We are
>  working on these issues, but in the mean-time you probably don't want to
>  make  it too easy to accidentally boot a non-SE kernel. 
Good to know.... 

I like the enforcing difference... I will move that way.
Setting enforcing to true is the next thing on my list.

Thank to all.

Later,
tom



-- 
	T o m  M i t c h e l l 
	/dev/null the ultimate in secure storage.

[Russell Coker]

On Wed, 10 Mar 2004 19:27, "Richard Hally" <rhally(a)mindspring.com&gt; wrote:
>  Fwiw, in grub I set up duplicate sections for a permissive kernel and
> an
>  enforcing kernel using ENFORCING on the title line and enforcing=1 on the
>  kernel line. 
That's the way to do it.  I sometimes do the same on my machines.  If you 
accidentally boot in permissive mode it won't do anything other than fail to 
enforce security decisions, after it's booted you can then put it in 
enforcing mode.

-- 
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

[Stephen C. Tweedie]

Hi,

On Wed, 2004-03-10 at 08:27, Richard Hally wrote:

>  If you accidentally boot a non-SE kernel then /etc/mtab and a few
> other
>  files
>  will get the wrong label, which will be really annoying for you. 
Yep, I noticed that one too.  Hard to miss it when the box won't boot.
:-)

I've been wondering how to minimise the pain of this.  If we can get a
shortlist of the inodes most likely to be bitten by bad labels, we can
check those on boot time, detect if there's a problem, and relabel from
(say) all of /etc (we can extend the list as we learn where the problems
are going to be.)

The more we make these things automatic, the less likely our users will
be to turn selinux off in frustration, so it's probably something we
should do for fc2-final.

--Stephen

[Russell Coker]

On Wed, 10 Mar 2004 22:24, "Stephen C. Tweedie" <sct(a)redhat.com&gt; wrote:
>  > If you accidentally boot a non-SE kernel then /etc/mtab and a
> few other
>  > files
>  > will get the wrong label, which will be really annoying for you.
>
>  Yep, I noticed that one too.  Hard to miss it when the box won't boot. 
/etc/mtab is a special case in that it's quite trivial and also very annoying.

I will change the policy to allow mount_t to read and unlink file_t:file.  
Then it should be able to do it's stuff.

Please put the following in your policy and see if it solves things for you 
next time you boot a non-SE kernel (sorry I don't have a machine I feel like 
booting a non-SE kernel on at the moment).
allow mount_t file_t:file { getattr read unlink };

-- 
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

[Stephen C. Tweedie]

Hi,

On Wed, 2004-03-10 at 08:03, Russell Coker wrote:

>  > Is it necessary/useful to do stuff like this before or after a
> reboot?
>  > Is there a difference from vanilla in how promptly a reboot and other
>  > housecleaning for SELinux is needed?  i.e. will audit go nuts...
>  
>  In general use there should not be any need for a relabel except after severe 
>  file system corruption, a backup/restore with non-XATTR aware backup 
>  software, or booting a non-SE Linux kernel. 
In practice I find my own SELinux test box becomes unbootable if I work
with `setenforce 0` for any length of time, and it takes a relabel to
fix things.  The main breakage seems to be that at boot time, e2fsck
can't access the glibc gconv modules list.

I've changed my relabel scripts so next time it happens, I'll do a
setfiles -v and record exactly what inodes are mislabelled.

Cheers,
 Stephen

[Stephen C. Tweedie]

Hi,

On Wed, 2004-03-10 at 01:40, Tom Mitchell wrote:

>  The more general question is that for  Large Medium and small
> updates....
>  there may always be a question when one or more "makes" in the policy
>  area will be needed.  Is there a good way to check... will make
>  check-all do the right thing?
>  
>     cd /etc/security/selinux/src/policy
>     make ?????  # lots of choices...
>     make relabel  # necessary? when and how to check ...
>  
>  Is it necessary/useful to do stuff like this before or after a reboot? 
It shouldn't be necessary.  But if there's something wrong ---
unexpected actions in a %post script, the rpm was built from the wrong
policy's file context list --- it might be.  I've added a new target in
my own policy makefile:

checklabels:  $(FC) $(SETFILES)
        $(SETFILES) -v $(FC) `mount | awk '/(ext[23]| xfs).*rw/{print $$3}'`
 
which passes the "-v" option to setfiles so that in addition to fixing
labels, it logs those inodes with the wrong labels.

--Stephen