On Wed, 2009-03-04 at 09:03 -0500, James Carlson wrote: > Peter Memishian writes: > > As Seb mentioned earlier, dlmgmtd provides this facility for libdladm. It > > also synchronizes all changes (e.g., two applications using libdladm at > > the same time cannot clobber each other), and provides a central point for > > other facilities, such as posting sysevent notifications for new datalinks. > > Besides the somewhat questionable duplication of the SCF mechanisms > that Sowmini cites, there's another important problem with the > existing dladm/dlmgmtd mechanism: security. > > The existing design checks that the caller holds sys_dl_config and/or > sys_net_config, but then doesn't go on to audit this access-granting > mechanism. The auditing (if any is done at all) is done out in the > *client* (see audit_secobj in dladm), and not where the access itself > is checked. > > 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. > User space things should be checking authorizations (with > chkauthattr(3SECDB)) instead of privileges, and then auditing the > results at the point where the enforcement is done. Agreed. > Going forward, I think it'd be really nice to see this work done in > SCF rather than scattered about in per-service daemons with local > reinventions of locking, security, notification, and other issues. I mostly agree with this (and I communicated the same sentiment to Girish and Sowmini yesterday over IRC), and we even had a long discussion years ago about migrating all datalink and IP configuration to SCF using per-link and per-interface service instances. It's probably time that we get serious about doing this (at least for IP interface configuration) if we want libipadm to be a usable and flexible API. 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? -Seb [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.
