[systemd-devel] setroubleshoot integration.

[Zbigniew Jędrzejewski-Szmek]

On Wed, Jan 16, 2013 at 06:16:55PM +0100, Lennart Poettering wrote:
> 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.
Yeah, that will work.

Zbyszek