On Fri, Apr 8, 2016 at 11:14 AM, M. J. Everitt <m.j.ever...@iee.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
