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

[Chris Wright <chrisw@sous-sol.org>]

* 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