file_labels_t

file_labels_t

[Chris PeBenito]

I was doing some cleaning (goodbye devfsd.{te.fc}), and I was thinking
that file_labels_t could be removed in new api policy, since psid is
gone.  However, when I was going through looking for the rules that had
it, I realized that it is still an initial sid.  Why is the initial sid
still around if psid is gone?  Because it requires a bit of a kernel
modification?

-- 
Chris PeBenito
<pebenito@gentoo.org>
Developer, SELinux
Hardened Gentoo Linux
 
Public Key: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xE6AF9243
Key fingerprint = B0E6 877A 883F A57A 8E6A  CB00 BC8E E42D E6AF 9243

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

[Stephen Smalley]

On Wed, 2003-10-01 at 00:59, Chris PeBenito wrote:
> I was doing some cleaning (goodbye devfsd.{te.fc}), and I was thinking
> that file_labels_t could be removed in new api policy, since psid is
> gone.  However, when I was going through looking for the rules that had
> it, I realized that it is still an initial sid.  Why is the initial sid
> still around if psid is gone?  Because it requires a bit of a kernel
> modification?

You can remove the type, and just map the initial SID to unlabeled_t
until we get around to cleaning up the initial SIDs.  Cleaning up the
initial SIDs does presently require rebuilding the kernel module with
updated headers so that it reflects the current values of the subsequent
initial SIDs, which will be perturbed by the removal of earlier initial
SIDs, so we would likely increment the policy version number at that
point.  The initial SID support needs to be reworked to support more
dynamic removal and extension; we originally expected the initial SIDs
to be very static, but that doesn't really seem to be the case.

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

[Russell Coker]

On Wed, 1 Oct 2003 23:56, Stephen Smalley wrote:
> You can remove the type, and just map the initial SID to unlabeled_t
> until we get around to cleaning up the initial SIDs.  Cleaning up the
> initial SIDs does presently require rebuilding the kernel module with
> updated headers so that it reflects the current values of the subsequent
> initial SIDs, which will be perturbed by the removal of earlier initial
> SIDs, so we would likely increment the policy version number at that

One way of addressing this is to never remove an entry until there is 
something else to take it's place, and to only add new entries on at the end.  
It seems much simpler to do that than to update the policy version number so 
often.

Also when we rename entries it may be easier to add new entries before adding 
the old entries so that the same policy source can be used to compile 
policies for two successive kernels.

One problem that we have is that the upgrade proceedure too often has been:
Build new kernel with new kernel source, compile new policy from new policy 
source, and install both at once.

This is fine if the new kernel works well.  If the new kernel doesn't work so 
well and if it has some bug that doesn't show up for some weeks or months 
(it's happened before) then you are left with a system that has had it's 
policy changed (or maybe even worse you don't know whether it's had any 
significant changes due to lack of change control) and you can't compile the 
newest changes to your policy for your old kernel.

This problem is exacerbated by the fact that there is only ever official 
releases for one kernel.  I haven't complained about this in the past because 
I have my own repository of SE Linux kernel patches (every kernel from 
2.4.19) and I'm happy to port each new NSA release to other kernel versions 
as necessary.

Of course this is something that distributions should and will take care of.  
I'm doing it for Debian and James will do it for Red Hat.  However at the 
moment I get the impression that a large portion (the majority?) of SE Linux 
users are just using the kernel patches from the NSA site.

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