[ale] GTK error

[Michael Trausch]

On Thu, Jan 27, 2011 at 4:12 PM, Jim Kinney <jim.kinney at gmail.com> wrote:
> With SELinux, /usr/bin/passwd is setuid 0 but /etc/shadow is set to
> ONLY allow access from /usr/bin/passwd (actually it uses a
> passwd_exec_t type). This splits off admin privileges from a user to a
> process.

If /etc/shadow is set to only allow access from /usr/bin/passwd, what
is the effect on applications that call PAM to carry out
authentication?  I think there must be something missing from your
description, otherwise /usr/bin/login or /usr/sbin/sshd would be
unable to verify a user's password when they present it at login on
the console or via SSH, respectively.  (Ignoring, for a moment,
configurations where passwords are banned.)

> As a user normally is logged in, they are running a non-privileged
> shell so that process is what calls the setuid passwd. That's what you
> want in your discussion :-)

More generically, any program can start a setuid program using the
normal exec() system call; upon processing the exec() system call the
kernel grants the privileges of the uid that owns the file to the
process; if the process is insecurely written (ignoring any kernel
level hardening, just talking about a standard system), then it's
possible to spawn another child process (or force the program to call
exec() again to reuse the same process) and keep the privileges
granted as a result of being setuid.  Bad stuff, of course.

In the case of things like PolicyKit, I'm not 100% certain how they do
that.  I don't think they use setuid at all; I think they spawn the
"server" process in response to an IPC request.  Not yet sure, but it
is on my list to research, someday.

> Most cases I've seen in modern linux, setuid is _very_ limited to only
> writing to /etc/[g]shadow or a user-called process that touches the
> hardware layer in a non-shared way. And most (if not all) of those are
> pretty well gone (sound stuff may be a hold out).

I have seen some systems that use embedded databases where the program
is started set[u|g]id so that it can access some data specific to the
application, but where the user cannot touch the data directly.  I
think that's probably a poor program design, though; I think that such
programs should instead be designed as client/server applications,
even if they are on the same system, such that the user interface is
separate from the privileged binary that runs in the background.  But
that's just me: separation of memory between processes and not letting
the user at the server process directly just makes good sense to me.
It doesn't have to be truly networked, either; after all, we do have
these cool little things called UNIX domain sockets.  :-)