tech-kern archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: pthread_setaffinity_np() permissions / secmodel sysctl(7)s

(CCing tech-kern)

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 secmodel modules.

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+).

Considering that:
- 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 correct one?

This is not exclusive to "usersetaffinity", the same goes on for "usermount" (allowing non-root users to mount file-systems).

Jean-Yves Migeon

Home | Main Index | Thread Index | Old Index