On Wed, Jan 16, 2013 at 06:16:55PM +0100, Lennart Poettering wrote: > On Fri, 11.01.13 21:23, Zbigniew Jędrzejewski-Szmek ([email protected]) wrote: > > > > > On Fri, Jan 11, 2013 at 09:03:52PM +0100, Lennart Poettering wrote: > > > On Wed, 09.01.13 22:52, Zbigniew Jędrzejewski-Szmek ([email protected]) > > > wrote: > > > > > > > > > We'd define a new special field OBJECT_PID. If this is included in > > > > > > a > > > > > > message, and that message comes from a privileged service, then > > > > > > journald > > > > > > will automatically add in OBJECT_EXE, OBJECT_UID, OBJECT_COMM, > > > > > > OBJECT_UNIT > > > > > > ... from /proc. > > > > OK, that would work too. How is "a privileged service" defined? > > > > > > As "not from a session cgroup" maybe? That would allow system services > > > that run under their own UID to make use of this functionality but > > > disallows this for user code. The same check is also used for splitting > > > off user journals: instead of simply splitting things up by UID we only > > > split up if the process has a session assigned, so that avahi and > > > friends (which run as avahi user) end up storing their stuff in the > > > system journal. > > > > I don't think that this is safe. We want to prevent spoofing of > > messages by unpriviledged processes. So an apache daemon running in a > > service should not be allowed to generate messages which would be > > displayed in 'journalctl -u UNIT', where UNIT is something different > > than the apache.service. journald messages are supposed to be trustworthy, > > and I think this includes the assumption that the user doesn't > > have to use 'journalctl -o verbose' to check the provience of > > messages. > > Hmm, so far we generally trust all system code, regardless under which > UID it runs. We distuingish "system code" from "user code" based on > whether they have their own session cgroup or not. > > It's an interesting point you raise, that one shouldn't trust > unprivileged system code either. > > > Maybe we could add an explicit field AllowJournalSpoofing=yes/no, > > defaulting to no of course, and set it to yes for setroubleshootd and > > a few other special services. > > If setroubleshoot runs as root, and is the primary usecase for this, > then I guess using an explicit UID=0 check here, for augmentation is OK > too. We can then reinvestigate the issue if another user for this > appears and actually runs unprivileged. Yeah, that will work.
Zbyszek _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
