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. Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/systemd-devel
