HOWTO add privileged code to the kernel without breaking LSM/SELinux

HOWTO add privileged code to the kernel without breaking LSM/SELinux

[James Morris]

If you add any new code to the kernel which exposes any kind of 
privileged operation to userspace, then it probably needs an LSM hook and 
subsequent changes to SELinux.

It would certainly be unreasonable to expect all kernel developers to know 
how to do this, however, it is usually very simple to determine when a new 
LSM would be needed as a first step.

The simple tests are: does the code you're adding perform any new DAC 
checks involving any of the user or group ID fields of a task?  Did you 
add a capable() call?  Does it call DAC helper functions?

If so, it's possible that a corresponding MAC check needs to be added via 
LSM; and I'd ask that you simply cc any or all of the LSM and/or SELinux 
maintainers when posting such patches upstream for RFC or inclusion.  We 
can work on the LSM and SELinux side of things if needed.

This will not cover every case, but I think it will cover most of the ones 
that are likely to come up in the future.  If in doubt, it won't hurt to ask.


(CC'd GKH hoping something of this can go into his kernel hacking howto).


- James
-- 
James Morris
<jmorris@namei.org>

Re: HOWTO add privileged code to the kernel without breaking LSM/SELinux

[Greg KH]

On Tue, Jun 06, 2006 at 02:51:48AM -0400, James Morris wrote:
> 
> (CC'd GKH hoping something of this can go into his kernel hacking howto).

I always accept changes/additions to Documentation/HOWTO, feel free to
and add this there and send me a patch.  (you will probably have to
describe what MAC and DAC mean though...)

thanks,

greg k-h

Re: HOWTO add privileged code to the kernel without breaking LSM/SELinux

[James Morris]

On Mon, 5 Jun 2006, Greg KH wrote:

> I always accept changes/additions to Documentation/HOWTO, feel free to
> and add this there and send me a patch.  (you will probably have to
> describe what MAC and DAC mean though...)

Ok, cool, will wait to see if there are any further comments.


-- 
James Morris
<jmorris@namei.org>

Re: HOWTO add privileged code to the kernel without breaking LSM/SELinux

[Chris Wright]

* James Morris (jmorris@namei.org) wrote:
> If you add any new code to the kernel which exposes any kind of 
> privileged operation to userspace, then it probably needs an LSM hook and 
> subsequent changes to SELinux.
> 
> It would certainly be unreasonable to expect all kernel developers to know 
> how to do this, however, it is usually very simple to determine when a new 
> LSM would be needed as a first step.
> 
> The simple tests are: does the code you're adding perform any new DAC 
> checks involving any of the user or group ID fields of a task?  Did you 
> add a capable() call?  Does it call DAC helper functions?

The set_task_ioprio changes would make a nice concrete example.

> If so, it's possible that a corresponding MAC check needs to be added via 
> LSM; and I'd ask that you simply cc any or all of the LSM and/or SELinux 
> maintainers when posting such patches upstream for RFC or inclusion.  We 
> can work on the LSM and SELinux side of things if needed.
> 
> This will not cover every case, but I think it will cover most of the ones 
> that are likely to come up in the future.  If in doubt, it won't hurt to ask.

On a related note.  When adding sysfs files, file perms (and for SELinux,
super block label) are the lowest common denominator for protections,
but should also be considered the last resort.  Smth 0644 may need e.g,
an explicit capable() check in ->store (in addition to the implicit
permission() check).

thanks,
-chris