Over the last few years, I've watched numerous PSARC cases come in and be caught up with not using the correct privilege as part of their design.
Now I find myself thinking about doing "access control" for various objects with IPFilter and by default I start thinking about "uid == 0" being special. What I want to do is allow something filesystem-like, where a process with the right access can add objects to a specific part of the kernel configuration but cannot delete or otherwise modify anything else that it wasn't responsible for. But at the same time, I want a "superuser" to be able to remove everything. When I bring myself back to privileges, the first thought that crosses my mind is "no, someone who's authorised to do /that/ isn't necessarily the one I want to be authorised for this." And if I think about it enough, I start to come to the conclusion that some of the privileges are now quite large in what they support (ick!) What I see in the privileges is a lot of granularity when it comes to the filesystem but we haven't done a lot with networking yet... I don't know if what I'm really searching for is PRIV_NET_FIREWALL or more. What I do know is that PRIV_SYS_NET_CONFIG seems very wrong because of the scope and nothing else in PRIV_NET_* seems to be well suited to the task on my mind. Related but on a tangent... How much work is it to expand the existing privilege framework to allow packages to deliver and define their own privileges? For example, to take IPFilter, if I wanted to define 10 new privileges that were private to it, how could that be supported? (Which is to say if IPFilter wasn't installed, they would never be defined.) Or is the intention for the tieing together of privilege with executable and roles meant to take care of that? Darren (I suspect this is one of those "hallway conversations" that really isn't about much but neither am I near or in any of the right "hallways.)
