>
> > Thanks. And you're aware that this still leaves dlmgmtd
> > vulnerable to attack. Running with uid 0 and no effective
> > or permitted privileges still means it has read access to
> > all root owned files.
>
>Yes, and based on a discussion Cathy and I had yesterday, we think it
>should be possible to change it to run as "dladm" instead ("noaccess"
>seems inappropriate since among other things, having the dlmgmtd door file
>owned by "noaccess" seems wrong). While we can try out using the "dladm"
>user, this change will have a subtle impact on accessing files that are
>either directly or indirectly accessed by dlmgmtd and its libraries, and
>thus it may take time to determine with certainty that it will work.
>
>So, in short, is the use of uid 0 with minimal privileges for a
>non-networked daemon a gating issue? Or could a change (if possible)
>from uid 0 to the dladm user be done as part of a future case?
In most cases we run such daemons as "daemon" (doesn't imply networking or
not) after it has initialized.
$ ps -fu daemon
UID PID PPID C STIME TTY TIME CMD
daemon 134 1 0 Dec 21 ? 0:10 /usr/lib/crypto/kcfd
daemon 4701 1 0 Dec 21 ? 0:00 /usr/lib/nfs/lockd
daemon 4581 1 0 Dec 21 ? 0:00 /usr/sbin/rpcbind
daemon 4602 1 0 Dec 21 ? 0:00 /usr/lib/nfs/statd
daemon 4916 1 0 Dec 21 ? 0:05 /usr/lib/nfs/nfsmapid
daemon 5725 1 0 Dec 21 ? 0:28 /usr/lib/nfs/nfsd
Generally speaking, there's no need to introduce a new user or use a uid
which has certain other properties (such as owning files)
Casper
