Darren Reed wrote: > 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. >
New privileges can be introduced, but we try to keep the name space flat. In other words, we don't want having one privilege to imply that you also have any others. Every required privilege should be explicit enabled. This makes it hard to make existing privileges more granular, since it might break existing configurations such as Rights Profiles or SMF manifests. Generally new privileges should be created for new operations that were not previous restricted. There is an API, modctl(MODALLOCPRIV, char *pr), to create new privileges dynamically but I don't think it is stable. It can fail if there are no unused bits in the (opaque) privilege structure. In that case, the structure must be expanded, which requires a full recompilation of the kernel. If you want to experiment with adding privileges dynamically, take a look at add_drv(1M), or the function check_priv_entry() in http://src.opensolaris.org/source/xref/onnv/onnv-gate/usr/src/cmd/modload/plcysubr.c#check_priv_entry . > 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? > As stated above, adding privileges dynamically isn't recommended. > 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.) > It would be better to add the privileges and have them in the kernel even when IPFilter is not installed. There is precedent for this. Trusted Extensions added about a dozen new privileges that are ignored unless TX is enabled. > Or is the intention for the tieing together of privilege > with executable and roles meant to take care of that? > Having privileges defined the Rights Profiles that don't exist in the kernel can cause problems for administrative interfaces. For example, the SMC gets its list of privileges by querying the kernel, so it can't deal with "undefined" privileges. --Glenn
