Re: capabilities patch: trying a more "consensual" approach

[Stephen Smalley <sds@tycho.nsa.gov>]

On Sat, 2006-09-16 at 00:52 +0200, David Madore wrote:
> Hi, Linux and LSM experts,
> 
> I would like to request some advice on how best to create an LSM for
> creating underprivileged processes in a way that will seem acceptable
> also to those Linux users and kernel hackers who don't want to hear
> about it (i.e., my patch should not mess more than necessary with the
> rest of the kernel).
> 
> In a nutshell, the goal is to do this: when the module is loaded, each
> task should have a "cuppabilities" variable, which is initially blank
> and, when certain bits are added to it (or removed, depending on your
> point of view), prevents certain system calls from succeeding.  This
> variable should be inherited across fork() and exec(), and some
> interface should be provided to add more cuppabilities (i.e., make a
> process less-than-normally privileged).
> 
> Now, if I understand correctly, the various alloc_security() LSM hooks
> do not stack well: if I want my module to be stackable after SElinux
> (and I do), I can't hook task_alloc_security() to create my variable,
> so I need to store these "cuppabilities" in a globally visible task
> field.  Do I understand correctly?  How acceptable is this?  (We can
> assume that 32 bits will be wide enough, so I'm not talking about
> adding huge amounts of data to the task struct.)

No, I think that is a losing strategy, and it defeats the purpose of
having LSM in the first place.  For now, I'd suggest just _not_
supporting stacking with SELinux until such a time as you've
successfully gotten your module merged, then later you can take up the
best way to support such stacking (whether via direct modification of
SELinux to enable chaining off of its security structures, or via the
"stacker" module previously implemented by Serge that lacks a real
motivating user, although that is contentious).

> Second, what would be the cleanest and most acceptable way to provide
> an interface to these new "cuppabilities"?  For example, should I add
> a new, dedicated, system call?  If so, should I provide new hooks to
> it in struct security_operations?  Or is, perhaps, prctl() a better
> path (then I would have to request a hook on that in SElinux)?  How
> can I best avoid breaking causing any disruption to the rest of the
> kernel?

For SELinux, we had to drop our syscall and re-implement the API via:
- /proc/pid/attr for process attributes (getprocattr and setprocattr
hooks)
- xattr API for file attributes,
- selinuxfs (pseudo filesystem) for control and other operations.  These
days you would use securityfs (it didn't exist at the time selinuxfs was
created).

-- 
Stephen Smalley
National Security Agency

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/