On Tue, Jun 30, 2009 at 12:18:44PM -0400, Theodore Tso wrote:
> 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.
OK.
> 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
we are not on crack and we are not running the daemon as root, we use
"uuidd" user and "uuidd" group, but without setuid.
> > 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.
I'm talking about non-setuid binary executed by non-root user.
> > 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.
yes, I care about (c) .
> 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).
Yes.
> ---- 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?
It's not about security... see Kay's response.
Karel
--
Karel Zak <kzak@xxxxxxxxxx>
--
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
