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...
On Wed, 10 Mar 2004 12:40, Tom Mitchell mitch48@yahoo.com 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.
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.
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
On Wed, 10 Mar 2004 19:27, "Richard Hally" rhally@mindspring.com 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.
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
On Wed, 10 Mar 2004 22:24, "Stephen C. Tweedie" sct@redhat.com 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 };
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
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
selinux@lists.fedoraproject.org