[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 10 Jun 2014 17:51:56 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: musl 1.0.x branch
On Tue, Jun 10, 2014 at 10:32:48PM +0200, u-igbb@...ey.se wrote:
> > For at least some of these (hosts and resolv.conf) I'd really like to
> > provide a way for users to override them at runtime. This is important
> > for testing and merely a matter of reasonable user convenience. But I
> > don't have a good idea for how to do it yet without various issues. :(
>
> > My feeling is that I want it to be "mildly hard by default" to change
> > these things and maintain the changes, since a lot of users will do it
> > without understanding the consequences. Especially when multiple
>
> I understand your concerns and yes each extra "degree of freedom" is risky
> especially when the concerned parties do not really know how to handle it.
>
> On the other side a switch like
> --I-really-know-what-I-am-doing-and-why=env-db-redirection-never-ever-suid
> makes a feature quite hard to choose without thinking at least a second :)
Sadly, I really doubt it does; it comes across as patronizing, which
annoys users with an "I know what I'm doing!" attitude.
In any case, it's also a matter of maintenance cost. Supporting
environment variables to override these things is not always trivial.
Some (most?) of these interfaces are required to be thread-safe and
accessing the environment is not thread-safe with respect to other
threads modifying it. There may also be storage/allocation burdens
when allowing a custom runtime path requires concatenating it with
another string. Even if none of this were difficult, it's extra
combinatorics for testing, and that issue was basically uclibc's
demise.
In the long term there may be ways we could change things upstream to
make it easier to maintain your changes -- for instance, replacing the
inline string literals with references to symbols. You could then
replace the const arrays the symbols refer to with non-const arrays
that get filled in at program startup (this is probably a lot safer
than calling getenv on demand, albeit slightly more bloated).
> > BTW if you could fully turn off suid at the kernel level, patching the
> > kernel to allow normal users to use mount namespaces and bind mounts
> > would be a great way to allow the kind of flexibility you want
> > globally (not just in libc) without any patching in userspace.
>
> What you suggest would be a redesign of the API, with yet not fully clear
> possibilities and consequences. This would also imply a new special way
> to administer hosts running such a kernel.
>
> Unfortunately this would not be sufficient for the purposes I think of.
>
> Our software is directly runnable on any host with e.g. a Linux-compatible
> ABI (or otherwise Posix-compatible API), _independently_ [sic] of how the
> host is administrated. We do not rely on any tweaks on the "host" level.
> (The only prerequisites are the availability of a file system with
> a global name space (like Coda, AFS, DCE/DFS) and allowed execve())
*nod* It's a shame this option isn't available in mainline kernels
though. It would be really nice if any user could do bind mounts with
a local fs/mount namespace and if doing so just precluded the suid bit
from taking effect in affected processes.
> > FYI you can emulate the usefulness of suid, without the danger, by
> > having a daemon on a unix socket that you connect to which provides
> > the functionality. This is a vastly superior design because there is
>
> Surely we are aware of this model being superior to suid - when necessary.
>
> Nevertheless, many of the cases where suid is being used are just due
> to mistakes in the very logic of the design.
>
> E.g. you do not need a suid helper (nor a daemon) to use PAM for your
> screensaver lock (the password hash does NOT have to be in "the"
> root-owned shadow file, nor do you need to check a Kerberos ticket
> against "the" root-owned keytab - the secrets belong to the security
> domain which they are to protect, in this case the security domain is
> not the host but the _user_ session).
>
> We solve this pretty straightforwardly by using environment variables,
> pointing to a relevant "shadow" file and/or pam configurations.
Note that the "tcb shadow" support in musl already provides this
functionality. For your purposes, of course, you already have path
override so it makes sense just to use the same tool you're using for
everything else. But for other uses outside yours, tcb shadow is a
really nice solution to this problem.
> > exactly one input channel to the code running with elevated privileges
> > (the socket) as opposed to unboundedly many (environment, open fds,
> > resource limits, working directory, priority, signal mask and
> > dispositions, cpu affinity, ... and whatever else the kernel folks add
> > in the future).
>
> You see, we often do not even have to rely on a single extra process
> with elevated privileges :)
>
> Thanks for taking my suggestions seriously. As I said I do not really
> expected much attention/support for our "unusual" usage pattern but I hope
> you see some sense in our approaches and in our reasoning.
Yes, it makes sense.
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
