assertions in kernel

assertions in kernel

[Russell Coker]

In assert.te we can prevent doing stupid things, for example if I never want 
to have a file labeled as root_t I can do the following:
neverallow domain root_t:file { relabelto create };

However doing this sort of thing means that we have to create asymetric policy 
regarding relabeling as if we get a file labeled as root_t (through a 
previous policy, through a file system error, or through kernel memory 
corruption resulting in bad data being written to disk) we need a way to 
label it back to some sane type.

I think that this approach does not work.  I think that to maintain sane state 
of the file system labeling we need to have some rules in the kernel, if 
those rules are violated (either on first access after boot or when a new 
policy load changes the rules) then the filesystem object gets relabeled to 
unlabeled_t.  Then setfiles only needs relabelfrom access to unlabeled_t to 
be able to fix all manner of file system stuff-ups.

I am aware that what I am suggesting involves a moderate amount of kernel 
coding (which I am not capable of doing).  However there has been some recent 
discussion for a number of new features in regard to kernel management of 
policy, so I presume that the feature list is up for discussion.

-- 
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: assertions in kernel

[Stephen Smalley]

On Wed, 2003-10-01 at 08:33, Russell Coker wrote:
> I think that this approach does not work.  I think that to maintain sane state 
> of the file system labeling we need to have some rules in the kernel, if 
> those rules are violated (either on first access after boot or when a new 
> policy load changes the rules) then the filesystem object gets relabeled to 
> unlabeled_t.  Then setfiles only needs relabelfrom access to unlabeled_t to 
> be able to fix all manner of file system stuff-ups.
> 
> I am aware that what I am suggesting involves a moderate amount of kernel 
> coding (which I am not capable of doing).  However there has been some recent 
> discussion for a number of new features in regard to kernel management of 
> policy, so I presume that the feature list is up for discussion.

The existing assertion checking support is likely to migrate into the
kernel in the future to allow a base set of assertions to be applied to
subsequent attempts to load policy modules.

-- 
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: assertions in kernel

[Russell Coker]

On Wed, 1 Oct 2003 23:58, Stephen Smalley wrote:
> On Wed, 2003-10-01 at 08:33, Russell Coker wrote:
> > I think that this approach does not work.  I think that to maintain sane
> > state of the file system labeling we need to have some rules in the
> > kernel, if those rules are violated (either on first access after boot or
> > when a new policy load changes the rules) then the filesystem object gets
> > relabeled to unlabeled_t.  Then setfiles only needs relabelfrom access to
> > unlabeled_t to be able to fix all manner of file system stuff-ups.
>
> The existing assertion checking support is likely to migrate into the
> kernel in the future to allow a base set of assertions to be applied to
> subsequent attempts to load policy modules.

But will it be enhanced to implement more functionality than is possible in 
checkpolicy?

Assertions such as "neverexist root_t:file;" are not possible in 
checkpolicy...

-- 
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: assertions in kernel

[James Morris]

On Wed, 1 Oct 2003, Russell Coker wrote:

> I think that this approach does not work.  I think that to maintain sane state 
> of the file system labeling we need to have some rules in the kernel, if 
> those rules are violated (either on first access after boot or when a new 
> policy load changes the rules) then the filesystem object gets relabeled to 
> unlabeled_t.  Then setfiles only needs relabelfrom access to unlabeled_t to 
> be able to fix all manner of file system stuff-ups.

I don't think relabeling files from kernelspace is a good idea.  A better 
approach may be to use an implicit label if a kernel assertion fails.


- James
-- 
James Morris
<jmorris@redhat.com>



--
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: assertions in kernel

[James Morris]

On Wed, 1 Oct 2003, James Morris wrote:

> I don't think relabeling files from kernelspace is a good idea.  A better 
> approach may be to use an implicit label if a kernel assertion fails.

Just to clarify following an off-list enquiry, what I mean by an implicit
label is that the kernel returns 'unlabeled_t' following an assertion
failure for a file, but does not change the disk structure.  This should
be transparent to the user APIs.


- James
-- 
James Morris
<jmorris@redhat.com>







--
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: assertions in kernel

[Stephen Smalley]

On Thu, 2003-10-02 at 07:43, James Morris wrote:
> On Wed, 1 Oct 2003, James Morris wrote:
> 
> > I don't think relabeling files from kernelspace is a good idea.  A better 
> > approach may be to use an implicit label if a kernel assertion fails.
> 
> Just to clarify following an off-list enquiry, what I mean by an implicit
> label is that the kernel returns 'unlabeled_t' following an assertion
> failure for a file, but does not change the disk structure.  This should
> be transparent to the user APIs.

The SELinux kernel module can internally mark the inode with the
unlabeled SID and use that for its own access controls, but it cannot
"filter" getxattr requests in this manner.  The LSM hooks only support
access control, not data filtering.  Hence, if you truly want the file
to appear to userspace as if it had the unlabeled context, then the
SELinux module would need to invoke the inode's setxattr method with
that context.

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