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 -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/54500660.5040...@iwakd.de
