Le Wed, 29 Oct 2014 00:52:54 -0400,
Marty <martyb@ix.netcom.com> a écrit :
On 10/28/2014 05:10 PM, Christian Seiler wrote:
> Am 28.10.2014 20:53, schrieb Marty:
>>> This just being one example of context being leaked. Some of this
>>> context could be cleaned up if uuidd were setuid root (and not
>>> setuid uuidd), but not all of it necessarily.
>>
>> From what you write it's not clear if a) there is an unavoidable
>> security threat in all use cases,
>
> Not necessarily a security threat, it could also just be unexpected
> behavior due to leakage of context. The problem is that there are so
> many possibilities of things that could happen in certain
> circumstances with things like this that it's not clear as to what
> the security implications are going to be, not that there
> necessarily are any.
>
>> and b) there is no way the systemd
>> replacement can co-exist with on-demand UUID in the same
>> executable.
>
> No, it could, no question.
>
>> Then if I read you correctly, the old mechanism may not work with a
>> promised future kernel security feature, but could be working
>> securely now in some use cases, albeit as a hack.
>
> I was never talking about future kernel versions. I was talking
> about lots of stuff that is still in the *current* kernel that
> incurs state that is passed on to children of processes. To name a
> few off the top of my head, that might cause problems, depending on
> the circumstances:
>
> - capability bounding set (cannot be directly escaped for a
> process, even as root)
> - SELinux context (depending on transition rules, maybe can't be
> escaped and certainly would need a specific rule for uuidd from
> every daemon that uses it)
> - seccomp syscall filters (usually can't be reset, even as root)
> - prctl(PR_SET_NO_NEW_PRIVS) (can't be reset)
> - nice priority (needs root to reset)
> - cgroup membership (needs root to reset)
> - PID namespace (if init of a PID namespace dies, all processes
> inside that namespace get SIGKILL)
> - and that's just off the top of my head
So granted, these are problems that need to be fixed, but they are in
Wheezy then people are already living with them and probably doing OK.
Problems are identified, some people wants to solve them. And we
shouldn't solve them, because of what?
There is a difference between being OK and being technically correct.
>
> Now I'm not saying that all of them are necessarily a problem, it
> really depends on what the concrete circumstances are. But the
> issue here is that for a general-purpose library that may be used
> by different services that may be subject to any number of the
> aforementioned contexts.
Could they have instead made the library call a no-op if systemd is
installed, instead of requiring the new dependency? People not using
systemd would not be any worse off than currently, and they would
likely be small in number. For those, the risk of using the old hack
should be weighed against the risk of a new, complex, and relatively
untested solution, relative to its size. Should the user be able to
decide that?
You still need to have something handling the systemd activation
protocol for systemd users. You either need to reimplement in the
executable (code duplication is bad) or depends against the library
that does that for you... And the later is the way (lot of) upstreams
have chosen.
The users who actually care are still free to revert patches and/or
drop configure flags to remove systemd socket activation support.
>
> So instead of shipping something that kind of sort of works in many
> cases now but that may cause some weird, unexpected and probably
> really hard to debug problems later, the authors decided to drop
> this logic and say: on systems without socket activation, it just
> has to always be started. uuidd, if always started, still works on
> those systems.
>
>> If that's right, then the way it was removed is the problem.
>
> As I said in my earlier mail: even if there had been no possibility
> to do a safe and secure on-demand activation (no init system with
> socket activation available) I still would have said that removing
> this on-demand hack and always starting uuidd would have probably
> been the best solution.
By "problem" I meant what I consider the problem of not having an
overlap between old and new solutions, and no deprecation period or
warning. I don't argue that it should not be corrected. My point was
more of a policy and design strategy issue.
There is NO functional change at all, what was working before is still
working now. The only difference is that you have an extra daemon
running from the start (and running in a clean context).