On Mon, Dec 1, 2014 at 5:50 AM, Daniel Mack <daniel@zonque.org> wrote:> Hi's> namespaces individually, so we can also take possible chroot()> environments into account to do path translations.Thanks!I suspect you'll get a lot of "(unreachable)/foo/bar".>>>> another item once we have a better source of information.I'll see if I can get highpid in soon enough that starttime can bedropped entirely. Once it shows up, there will be an API that canprobably never be removed that isn't namespaced correctly and can't becheckpointed.>>>>  user> namespace to another, which means we cannot allow such an item to cross> user namespaces. We can add this functionality later once we have the> neccessary APIs.I still don't expect this metadata item to ever make sense to use.The best argument I've heard is that it would enable CAP_SYS_BOOT toask systemd for a reboot. I think this is bogus:Realistically, this probably just means that users of /sbin/rebootmight continue to work as expected. Except:1. CAP_SYS_BOOT was never sufficient for /sbin/reboot to rebootcleanly -- clean reboots historically went through /dev/initctl.2. This only makes sense anyway if /sbin/reboot gets updated to speakdbus. So you have a new reboot binary that you want to work as longas it ends up with CAP_SYS_BOOT. But caps are so broken that thiswon't work intelligently no matter what kdbus does. A user can haveCAP_SYS_BOOT or not, but whether or not /sbin/reboot inherits that bitis almost entirely a function of that user's euid and has very littleto do with whether that user has CAP_SYS_BOOT. So you might as welljust check euid == 0 in the first place.And setting fscap bits on /sbin/reboot so that a new reboot binary canprove to systemd that it has CAP_SYS_BOOT makes no sense. Either putthe policy in systemd in the first place, or make /sbin/reboot setuidroot.And passing the permitted, inheritable, and bounding sets makes evenless sense. Yes, you could pass the entirety of /proc/PID/stat and/proc/PID/status, but that's silly, and passing caps around via kdbusfor diagnostics seems ridiculous.If you put it in now, it's here to stay even if it proves to be a badidea, whereas if you don't put it in at first, you can always add itif a good reason comes> are in place. Until then, we'll expose the same information as other> parts of the Linux API already do.I don't expect this to become a problem.>>>> +> other> security checks, then they need to call into libselinux, and should do> that by taking the enforcing mode into consideration. This is already> done in a lot of software that way.>>> Also, there should be a justification for why the LSM hooks by>> themselves aren't good enough to remove the need for this.>> SELinux and other MACs might want to do additional per-service security> checks. For example, a service manager might want to check the security> label of a service file against the security label of the client process> using the SELinux database before allow access. For this, we need to be> able to pass the client's security label race-free to libselinux so that> it can make its decision.Yeah, but what happens on systems that use a different LSM? And isn'tthe point of the new LSM kdbus hooks to do this automatically withoutuserspace's help?Admittedly, I don't see much of a problem with this feature existing,as long as the non-selinux people are okay with it.>> I've added the above to the documentation now.>>>> Thanks for your review again - much appreciated!And thanks for addressing most of the issues. The code is starting tolook much better to me.--Andy