[ale] GTK error

[Jim Kinney]

On Thu, Jan 27, 2011 at 4:41 PM, Michael Trausch <mike at trausch.us> wrote:
> 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?

getent is allowed to read from /etc/shadow as is login so it's not
_totally_ of limits. But that makes it really hard to access the
password hash database without proper authority.

  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.  :-)
> _______________________________________________
> Ale mailing list
> Ale at ale.org
> http://mail.ale.org/mailman/listinfo/ale
> See JOBS, ANNOUNCE and SCHOOLS lists at
> http://mail.ale.org/mailman/listinfo
>



-- 
--
James P. Kinney III
I would rather stumble along in freedom than walk effortlessly in chains.