journald bypassing MAC checks?

[Florian Weimer]

systemd-journald has a facility where it accepts file descriptors from 
unprivileged local users and reads the log message from them.  This is 
done to bypass size restrictions on UNIX domain socket datagram messages.

The code is here in server_process_native_file:

http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-nat...

Does this bypass MAC checks because the journald process has different 
privileges than the user who opened the file descriptor?

-- 
Florian Weimer / Red Hat Product Security Team

[Stephen Smalley]

On 04/23/2014 12:10 PM, Florian Weimer wrote:
>  systemd-journald has a facility where it accepts file descriptors
> from
>  unprivileged local users and reads the log message from them.  This is
>  done to bypass size restrictions on UNIX domain socket datagram messages.
>  
>  The code is here in server_process_native_file:
>  
>  http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-nat...
>  
>  
>  Does this bypass MAC checks because the journald process has different
>  privileges than the user who opened the file descriptor? 
SELinux would check access by the user process at open time, and then it
would check access by journald on the fd transfer across local socket
IPC (selinux_file_receive hook), and then it would revalidate that
journald still has access when it reads from the fd.

Then I guess the question is what does journald do with the log message
it reads from the file, e.g. does it write it to the journal and then
who is allowed to read from the journal.  In a MLS environment, for
example, I would expect the journal to be unreadable except by
systemhigh processes as it might contain data from any level.

[Daniel J Walsh]

On 04/23/2014 01:19 PM, Stephen Smalley wrote:
>  On 04/23/2014 12:10 PM, Florian Weimer wrote:
> > systemd-journald has a facility where it accepts file descriptors from
> > unprivileged local users and reads the log message from them.  This is
> > done to bypass size restrictions on UNIX domain socket datagram messages.
> >
> > The code is here in server_process_native_file:
> >
> > http://cgit.freedesktop.org/systemd/systemd/tree/src/journal/journald-nat...
> >
> >
> > Does this bypass MAC checks because the journald process has different
> > privileges than the user who opened the file descriptor?
>  SELinux would check access by the user process at open time, and then it
>  would check access by journald on the fd transfer across local socket
>  IPC (selinux_file_receive hook), and then it would revalidate that
>  journald still has access when it reads from the fd.
>
>  Then I guess the question is what does journald do with the log message
>  it reads from the file, e.g. does it write it to the journal and then
>  who is allowed to read from the journal.  In a MLS environment, for
>  example, I would expect the journal to be unreadable except by
>  systemhigh processes as it might contain data from any level.
>  --
>  selinux mailing list
>  selinux(a)lists.fedoraproject.org
>  https://admin.fedoraproject.org/mailman/listinfo/selinux 
Yes I think the journal
should be at SystemHigh.  One potential problem
we have is if journald is reading the audit.log, sysadm_t would be
allowed to read it if it was running at SystemHigh even with separation
between sysadm_t and secadm_t.  We might have to do something to block this.

[Florian Weimer]

On 04/23/2014 07:19 PM, Stephen Smalley wrote:

>  Then I guess the question is what does journald do with the log
> message
>  it reads from the file, e.g. does it write it to the journal and then
>  who is allowed to read from the journal.  In a MLS environment, for
>  example, I would expect the journal to be unreadable except by
>  systemhigh processes as it might contain data from any level. 
The log message is written to the journal (a file under 
/var/log/journal), from where it can be retrieved by the user who 
submitted the FD under certain circumstances.  The journal log file has 
an ACL which grants read permissions to the user, assuming that the 
message was routed to the user's UID (which depends on journald 
configuration).

However, with Fedora's targeted policy, this might not work because 
journald is likely not allowed to read the file.

-- 
Florian Weimer / Red Hat Product Security Team