I briefly reviewed the current CAP_SYS_ADMIN capabilities, and I
didn't see any obvious commonality which would make it easy to define
an equivalence set. I'm not sure this is feasible or makes sense. I'm
also not confident of trying to split CAP_SYS_ADMIN as it's
traditionally been attempted (aka the CAP_SYSLOG type changes). It's
not going to scale to the hundreds of users of this capability.
Instead, as a strawman proposal, what if we introduced "capability
families"? A capability family is essentially a namespace for
capabilities. More specifically, instead of a call like:
if (!capable(CAP_SYS_ADMIN))
return -EPERM;
what if we modified the capable() call to take an extra string argument
if (!capable(CAP_SYS_ADMIN, "virtual_mem_subsystem"))
return -EPERM;
On the SELinux side, we can use the family string to assign names to
labels, and do a capability check against a particular label.
On the traditional DAC side, we could introduce a new prctl(), say
prctl(PR_CAPSET_FAMILIES), which took an array of strings which
restricted capabilities to the allowed families.
prctl(PR_CAPSET_FAMILIES, [ "virtual_mem_subsystem", "dev_random_subsystem" ])
On the prctl side, we'd need to think through the process lifecycle
problem. For instance, we wouldn't want a process to be able to update
it's list of allowed capability families, otherwise a process could
gain capabilities it shouldn't have access to.
DAC backwards compatibility is straight forward. If a process doesn't
opt-in to capability families, security controls remain the same.
-- Nick
On Tue, Nov 22, 2016 at 6:15 AM, Stephen Smalley <sds@xxxxxxxxxxxxx> wrote:
> > Has anyone given any thought into technically what we could do to have
> > finer grained LSM control here? I have some ideas here, but I'd like
> > to read about what has been previously been suggested...
>
> In general, we would audit the current set of CAP_SYS_ADMIN checks,
> prioritize the most significant ones, organize them into equivalence
> classes, and only define a single LSM hook and SELinux permission check
> for each equivalence class. That's if you want to just add
> finer-grained LSM hooks and leave the CAP_SYS_ADMIN checks alone.
>
> If you want to split CAP_SYS_ADMIN into finer-grained capabilities, then
> an example of doing that in the past was CAP_SYSLOG; you can see how
> they provide backward compatibility there. However, that is only
> sufficient if you only need to perform a check based on the process'
> credentials; if you want to take into consideration any object (e.g. in
> the case of swapon, the target file) or any other parameters, then
> you'll want a LSM hook instead.
--
Nick Kralevich | Android Security | nnk@xxxxxxxxxx | 650.214.4037
_______________________________________________
Selinux mailing list
Selinux@xxxxxxxxxxxxx
To unsubscribe, send email to Selinux-leave@xxxxxxxxxxxxx.
To get help, send an email containing "help" to Selinux-request@xxxxxxxxxxxxx.
