Re: Perfect Jessie is something like this...
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
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.
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.
>> Obviously, the latter part is not optimal for you, but uuidd will keep
>> working on your system, so I don't see what the huge problem is.
>
> Except that the work around won't be in Jessie AFAICT.
I didn't check, but if Jessie's uuidd doesn't start automatically on
non-systemd systems, then this is clearly a bug and a bug report should
be filed.
> The parent poster
> has to waste time tracking it down the script and background
> information, assume it's untested, hope that it works, and hope that the
> relevant messages explaining it have not expired from the mailing list
> archives (util-linux-ng). He's mostly on his own, fixing a problem that
> probably should not have happened in the first place, if my hypothesis
> is correct.
There's a reason why Jessie is still testing and not yet stable, and if
you do find bugs, please report them so they may be fixed.
> Even if the script were supplied and works as advertised, it
> still could mean upgrade breakage, depending on the use case.
In what way? If somebody had uuidd installed in Wheezy and then upgrades
to Jessie, there should be no breakage if the script is also updated,
because then uuidd should always be started.
> The possibility of vendor lock-in is hard to ignore in cases like this.
Why do you consider this 'lock-in'? There was clearly NO intention of
dropping support for non-systemd systems (see the util-linux mailing
list posting I referenced earlier), other than for the on-demand logic,
and if there really was a problem with always starting the daemon, then
that was a bug, which is unfortunate, but not the first time that a new
software version broke something.
> My concern would be how many
> backwards-incompatibility cases like this are lurking in Jessie? Are
> more being added each day?
Every transition breaks something. I know it can be frustrating if stuff
doesn't work as expected, but if you file bug reports, then things will
have a large chance of getting fixed. In the vast, vast majority of
cases, upstream developers and Debian maintainers do actually care about
making its software work without systemd (which is why util-linux still
ships an init script for uuidd, even upstream).
Christian
Reply to: