Peter Memishian writes: > > 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. > > I'm not sure I follow this. If you have sufficient privileges, you can > always bypass auditing by writing your own utilities.
I think I agree with you, except that the mechanism in this case is protecting writes to a file rather than privileges for kernel actions. Holding sys_dl_config isn't enough (by itself) to write to any of the stored wireless key material -- except that there's a hole (an unnecessary one in my opinion) granted by dlmgmtd that makes this privilege alone equivalent to being given solaris.network.link.security authorization. The general principle I'm asserting is that as long as you're in user space, you should have the check for an authorization and the auditing of that action close to the actual access. If the user interface or support library is separated in user space by a door or some other IPC from the daemon doing the work, then use the secure credential-passing mechanism, and do the *authorization* check in the daemon that actually makes the changes; don't use a privilege to check for that authorization by proxy. Separating them in user space by use of a shared privilege (sys_dl_config means both network management *and* link security) doesn't seem wise to me, and likely makes it much harder to show that the design implements the access rules properly. It certainly doesn't conform to anything I thought I understood about RBAC. -- 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
