Re: [gentoo-dev] usr merge

[Rich Freeman]

On Fri, Apr 8, 2016 at 11:14 AM, M. J. Everitt <m.j.everitt@×××.org> wrote:
> Being serious though, and playing Devil's Advocate of course, assuming
> you have no use for a desktop manager, etc, hence no need for dbus or
> it's 'friends' and policykit or it's pals, and you're not a "systemd
> fan" etc .. how are we granting the correct permissions for binaries ..
> just relying now on the owner and execute bits being set perfectly for
> each binary, assuming everything is arbitrarily moved to /xbin ...

If you're relying on file permissions on binaries (other than the suid
bit) you're doing it wrong.

There is no harm in a non-privileged user executing /sbin/shutdown in
the non-systemd world, because init isn't going to listen to an
unprivileged user.  In a systemd world the shutdown command will talk
to systemd via dbus and dbus will use policykit to determine whether
the message should be allowed to go through (at least, I think it is
dbus that does this, and not the message recipient, but either way it
is getting checked).

Most security is provided by the kernel and posix capabilities.  If a
process has a capability, then the kernel lets it do something.
Without that capability, simply making some system calls won't do
anything.  Policykit is an extension of this into userspace, since
userspace governs a lot of important functions.  You could view
policykit as a sort of posix capability set for userspace.

The traditional suid way of doing things blurs the lines a bit, but in
general most suid-root binaries don't rely on whether you can execute
them as a form of policy.  Usually they have some kind of internal
policy management which is more flexible.  Sure, you might be able to
keep somebody from changing their password by playing with the
permissions on /bin/passwd.  However, you're probably better off
tweaking the configuration of PAM/etc.

-- 
Rich