On Thu, 20.06.13 21:48, Lennart Poettering (lenn...@poettering.net) wrote: > On Wed, 12.06.13 00:42, Zbigniew Jędrzejewski-Szmek (zbys...@in.waw.pl) wrote: > > > When journald encounters a message with OBJECT_PID= set > > coming from a priviledged process (UID==0), additional fields > > will be added to the message: > > > > OBJECT_UID=, > > OBJECT_GID=, > > OBJECT_COMM=, > > OBJECT_EXE=, > > OBJECT_CMDLINE=, > > OBJECT_AUDIT_SESSION=, > > OBJECT_AUDIT_LOGINUID=, > > OBJECT_SYSTEMD_CGROUP=, > > OBJECT_SYSTEMD_SESSION=, > > OBJECT_SYSTEMD_OWNER_UID=, > > OBJECT_SYSTEMD_UNIT= or OBJECT_SYSTEMD_USER_UNIT=. > > Hmm, so, do we really want to call this "OBJECT_"? There were ideas to > call it "AUGMENT_" or so... But hmm, maybe "OBJECT_" is better as for > the final viewer it is irrelevant whether journald augmented this or > didn't. Kay, any opinion how this should be called? Otherwise it's > probably good to stick to OBJECT_... > > > Actually the restriction that the sender is priviledged is not very > > important, since we are just adding "normal" fields, that the process > > could add itself. I'm keeping it because of the potential information > > leak, where a process has access to the journal but is restricted > > from /proc. > > Hmm, also, should this be _OBJECT_EXE= rather than OBJECT_EXE= > (i.e. trusted vs. untrusted)? after all, if journald writes them these > fields are not fakeable... > > Hmm, but then again it probably is a good idea that fields we add in > that depend on untrusted fields should be considered untrusted. So I > guess OBJECT_EXE= is right, and better than _OBJECT_EXE=... > > > The reader side is more important. We need to figure out how > > to show this information in journalctl and systemctl status, and > > how to figure out if OBJECT_* fields can be trusted. But let's > > decide that after we have the answer to the first two questions. > > Filtering for OBJECT_SYSTEMD_UNIT=foobar.service UID=0 should work for > this, too, no?
An addendum: the only problem I see with this concept is the fact that this is racy: if journald adds in these fields the original process might be long gone already, so that we cannot add that data. We have the same problem with the normal fields like _EXE= and so on, and we'll hopefully get them fixed eventually by kdbus and by getting SCM_CGROUP, SCM_PROCINFO and so. However, for the selinux case this wouldn't be sufficient. That said, I don't think this is a deal-breaker. I think haveing OBJECT_PID= in place still makes a ton of sense, and it is trivial to do. Also should the selinux side eventually grow support for race-free gathering of these bits, then we could still support that very easily: journald should only augment things if the individual field doesn't exist yet... Lennart -- Lennart Poettering - Red Hat, Inc. _______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/systemd-devel
