(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 privileges 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 jeanyves.migeon%free.fr@localhost