[systemd-devel] [RFC PATCH] journal: allow callers to specify OBJECT_PID=

[Lennart Poettering]

On Thu, 20.06.13 21:48, Lennart Poettering (lennart at poettering.net) wrote:

> On Wed, 12.06.13 00:42, Zbigniew Jędrzejewski-Szmek (zbyszek at 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.