On Mon, Feb 02, 2009 at 12:12:56PM -0500, Will Young wrote: > Darren Reed wrote: > > I must confess that I'm feeling quite alarmed at how many different > > actions are falling under PRIV_SYS_NET_CONFIG. It's like > > anyone with that privilege is the "network superuser", which kind > > of scares me. Which is why I'm asking "where are privileges going?" > > Does that one privilege really need to be reused amongst so many > > different programs/features? > > While there is a general sentiment of the finer grain the better, I > think our first priority is the limiting running with any elevated > privileges. If this is done correctly there is no literal "network > superuser" in that users are given the privilege only when it is > constrained by specific commands which can enforce more complex rules > than the kernel privilege model.
Use of RBAC (as you [Will] mentioned) mitigates the lack of granularity. In fact, RBAC profiles and authorizations -- not privileges -- are the preferred way to grant users specific permissions. Privileges are more of a design detail. Breaking up a too-coarse privilege makes sense from a privilege separation point of view as protection against bugs in user- land software. OTOH, privilege names are public interfaces (hmmm, privileges(5) lacks an ATTRIBUTES section). So I don't see how we can avoid hierarchical privileges when breaking up very large privilege names that may have ended up getting hardcoded into third party code (if they are only hardcoded in third party SMF manifests' method_contexts, then SMF could replace old names with new ones). It'd be nice if we could come up with rules for how to break up a privilege. Nico --
