> Comparing noaccess and daemon, I agree that there is little difference
> between the two. (ISTR however that NFS had some special handling
> around noaccess, or maybe that is nobody. I never did anything that
> relied on the special semantics, in any case.)
NFS special cases nobody (and nobody4). I don't recall the
rules around user daemon. The rules around user noaccess is
that there are to be no objects owned by the "noaccess" user
or group. "daemon" being an historic user/group might have
objects owned by it. In fact user "bin" and "adm" are in group
"daemon". AND worse, user "daemon" is in group "root". User's
"daemon", "bin", "adm" all allow for cron jobs run as them thus
making them more dangerous accounts than "noaccess" which has no
such provisions.
Gary..
> HOWEVER, one could reasonably argue *separate* UID/GIDs could be used to
> provide better security isolation. I.e., it makes sense that if someone
> finds a hack for nbtd, that we might not want that to create an exposure
> for kcfd, or nfsd, etc. (E.g. imagine that you can now attach a
> debugger to nfsd because you hacked nbt...)
See above. An exploit of a service running as daemon could
create cron jobs that would run with group root.
> It would be really nice if we had a better way to allocate special
> purpose UIDs for these sorts of things, without worrying about
> collisions with site use of UIDs or collisions with other OS' use of
> UIDs (for shared NIS maps, for example.) Almost like a completely
> different number space for system use only, that was guaranteed not to
> collide with any other UIDs. Gary, do you have any thoughts here? (I
> realize that such a project is far outside of the scope of this project,
> although the notion of possibly selected a different low numbered UID
> for nbt seems not entirely out of scope.)
Yes that's out of this cases scope. See the OpenSolaris
Fine Grained Access Policy (FGAP) project for binding a
process/user to a set of objects it can view and or modify.
Gary..
