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-native...
Does this bypass MAC checks because the journald process has different privileges than the user who opened the file descriptor?
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-native...
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.
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-native...
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@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.
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.
selinux@lists.fedoraproject.org