Sebastien Roy writes:
> On Wed, 2009-03-04 at 09:03 -0500, James Carlson wrote:
> > Someone with those privileges could write his own non-auditing utility
> > and just walk right by this security measure. That isn't supposed to
> > happen.
>
> Yes, this is indeed a problem, but is this not a bug that can be fixed
> by simply adding authorization checks and auditing to dlmgmtd? Unless
> I'm missing something, this lack of auditing authorization checks it's
> not an architectural flaw in the design. The only related flaw in the
> design that I can see is that it is an outright duplication of what SCF
> and svc.configd is designed to do, which admittedly isn't a good thing.
That's part of the point. The other part of the point is that when
you've got multiple wheel inventions floating around, some of them are
bound to be a little less roundish than others.
> What does that mean for this project, though? If SCF isn't being
> considered and this proposal goes forward with its limitation that all
> libipadm consumers (except for ipadm) need to be setuid root [1], will
> NWAM be able to use this?
I don't think it's a problem for nwamd, but contacting that team to be
sure is probably the best answer.
> [1] I'm assuming that requiring consumers to be setuid ipadm is a
> non-starter, as we must have an underlying assumption that consumers of
> the API are doing more than calling libipadm functions.
If that's what's being done, it probably needs to be privilege-aware
and bracket the functions that require special privileges. The
library _could_ help with that part.
Another possibility would just be tossing the back-end functionality
into dlmgmtd. Yes, I realize that "IP" isn't a "datalink" and so the
functions clearly don't belong there, but:
- It means we have one fewer daemon that just takes up a process
slot and rarely if ever does anything interesting.
- It means we don't have to duplicate whatever security and auditing
stuff we might do.
- It recognizes that the whole scheme isn't a template we should be
reproducing.
- It maybe gives us a little more incentive to move over to SCF/SMF
real-soon-now.
--
James Carlson, Solaris Networking <james.d.carlson at sun.com>
Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
