[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: pthread_setaffinity_np() permissions / secmodel sysctl(7)s
On 03.11.2011 10:38, Jean-Yves Migeon wrote:
On Wed, 2 Nov 2011 22:36:58 -0400, Thor Lancelot Simon wrote:
On Thu, Nov 03, 2011 at 03:30:54AM +0100, Jean-Yves Migeon wrote:
Should not? I took the same logic as the one allowing usermounts.
It's a matter of policy though.
None of the security sysctls should be changeable at securelevel 1 or
higher. Certainly it should not be possible to grant additional
to non-root users. Is there logic somewhere else preventing it, like
in the relevant kauth listener perhaps?
None, the checks are simply not implemented in secmodel_securelevel(9).
I'll have a look this evening.
This has to be done for each variable though depending on their use: in
usermount/usersetaffinity cases, it's reasonable to deny additional
rights to non-root users, but turning off these rights should still be
permitted even when securelevel is set to 1+.
I hit an interesting scenario here -- an interdependency problem between
Context: have a sysctl knob that allow users to control CPU affinity(3),
like "security.models.suser.usersetaffinity". The variable can be set to
1 when securelevel is -1 or 0, and to 0 anytime (e.g. you can bring it
down, but never up when securelevel is 1+).
- securelevel variable is static and managed by secmodel_securelevel(9)
- the "usersetaffinity" sysctl(7) knob is part of secmodel_suser(9)
I can't have access to securelevel variable from secmodel_suser, so
implementing checks to test whether we are allowed to change the sysctl
value is tricky in suser... as I believe its wrong to have an explicit
dependency between suser and securelevel secmodels.
Putting everything in bsd44 would be a possibility, but is it the
This is not exclusive to "usersetaffinity", the same goes on for
"usermount" (allowing non-root users to mount file-systems).
Main Index |
Thread Index |