Re: [PATCH] [request for inclusion] Realtime LSM

[Chris Wright]

* Peter Williams (pwil3058@xxxxxxxxxxxxxx) wrote:
> But the patch you describe still seems a little loose to me in that it 
> doesn't control both which users AND which programs they can run. 
> Although I suppose that can be managed by suitable setting of file 
> permissions?

rlimits are typically handled per user or per group.  this is set during
login and the limits apply to the users session.  none of the solutions
limit which programs the user can run, however strictly group based priv
granting can reduce the number of processes with the privs (using setgid
programs).

> Also I presume that root privileges are needed to set the rlimits which 
> means that the program has to be setuid root or run from a setuid root 
> wrapper.  In the first of these cases the program will be running for a 
> (hopefully) short while with way more privilege than it needs.  This is 
> why I'm attracted to mechanisms that allow programs to be given a subset 
> of root's privileges and only for specified users.

typically this is handled via pam during login, so yes, root (or more
specifically CAP_SYS_RESOURCE) is required, but need not be in any
wrapper.  limiting the allowed programs a user/role/domain/context/etc
can run is the goal of other type of security restrictions (such as
SELinux).

> I would be nice to have a solution to this particular problem that fits 
> in with such a generalized "granular" privilege mechanism (when/if such 
> a mechanism becomes available in the future) rather than a quirky fix 
> that is specific to this problem and doesn't generalize well to similar 
> problems when they arise in the future.  However, I agree with your 
> opinion that granting CAP_SYS_NICE is dangerous without some limit on 
> the priority levels is dangerous and think that a generalized "granular" 
> privilege mechanism would need to include such restrictions.
> 
> >The patch does not attempt to do any
> >"damage control" of abuse caused by RT tasks, and is hence much simpler
> >than my patch or Con's SCHED_ISO patch. ("damage control" could be done
> >from userspace anyway)
> 
> Yes.  In kernel "damage control" is an optional extra not a necessity 
> with this solution.  Not so sure about with the RT LSB solution though.

This has one advantage over RT LSM in that area, which is it places an
upper bound on the priority (in control of the admin).  So it's possible
to save some space for damage control in the top few prio slots.

thanks,
-chris
-- 
Linux Security Modules     http://lsm.immunix.org     http://lsm.bkbits.net
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/