[systemd-devel] setroubleshoot integration.

[Lennart Poettering]

On Fri, 11.01.13 21:23, Zbigniew Jędrzejewski-Szmek (zbyszek at in.waw.pl) 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 (zbyszek at in.waw.pl) 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.