On Tue, Jun 30, 2009 at 04:18:54PM +0200, Karel Zak wrote: > > I think the scenario when the library is starting the daemon is > very odd and should be reviewed ;-) > > Is there any Linux distribution with the setuid uuidd? Suse and > Fedora/RHEL use init scripts and fork()+exec() in the library is > waste of time. Debian and Ubuntu runs with the setuid uuidd, and starts it up from the library. The basic rationale behind doing things that way is that uuid generation doesn't happen *that* often, and keeping a daemon running all the time just for that purpose is Just Silly. My understanding from why Red Hat (and perhaps SuSE too) runs it as a daemon is that some security teams are on crack and somehow believe that running a daemon as root 100% of the time (where a buffer overrun could cause privilege escalation to root) is somehow *more* secure than running a damon which is setuid to an unprivileged userid such as libuuid, where an exposure would only cause someone to be able to overwrite the clock state file. So at least when uuidd was first included the Red Hat packager went the route of an init script and running uuidd as root because it was resulted in fewer bureacratic hoops he had to jump through. > Try "strace -f uuidgen -t" .. so many syscalls and the final result > is EACCES. Well, the EACCESS is from the fact that you're trying to ptrace a setuid binary. > It would be nice to check access to /var/run/uuidd (or > /var/lib/libuuid) before the exec() on all systems without setuid > uuidd. We already try to connect to the uuidd daemon first, and then check for the uuidd daemon's existence, before doing the fork/exec. So the failure case you are worried about only occurs when (a) the uuidd daemon is installed, but (b) the uuidd daemon is not running, and (c) it is not installed setuid. We could add some code that checks to see if daemon is setuid or setgid, and if it is not, that the current user has access to /var/run/libuuidd (I think a dynamic run-time test is suprior to a static compile-time switch) ---- but maybe it would be better to jump through distros' stupid security bureacracy, on the grounds that a setuid libuuid daemon is in fact much *safer* than keeping uuidd running as root all the time? - Ted -- To unsubscribe from this list: send the line "unsubscribe util-linux-ng" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
