From: nicolas.iooss@m4x.org (Nicolas Iooss)
Date: Mon, 11 Jan 2016 23:06:45 +0100
Subject: [refpolicy] [RFC PATCH] Add an interface for systemd services
 logging config
In-Reply-To: <20160111204111.GA15886@x250>
References: <1452539261-17628-1-git-send-email-nicolas.iooss@m4x.org>
	<20160111204111.GA15886@x250>
Message-ID: <56942775.6050901@m4x.org>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On 01/11/2016 09:41 PM, Dominick Grift wrote:
> On Mon, Jan 11, 2016 at 08:07:41PM +0100, Nicolas Iooss wrote:
>> Many systemd services use log_parse_environment and log_open systemd
>> functions to configure the way they log messages.  These functions
>> require permissions like reading /proc/cmdline and /proc/1/environ to
>> run properly, and then the service which used them needs to be able to
>> send messages over /run/systemd/journal/socket Unix socket.  When
>> connecting to the socket, systemd tries to modify the sending buffer
>> with setsockopt(fd, SOL_SOCKET, SO_SNDBUFFORCE, ...), which fails when
>> CAP_NET_ADMIN is not allowed, in which case it falls back to SO_SNDBUF.
>> Therfore CAP_NET_ADMIN does not need to be granted to every systemd
>> service using logging.
> 
>> As all these accesses are shared among many systemd services, create an
>> interface to allow them all at once.
> 
> I suspect that this is not limited to just systemd services.

I have not yet encountered such services, even though I know some
systemd services which I don't know yet where their policy will be in
refpolicy (systemd-cryptsetup, systemd-modules-load, etc.).

> Another thing i noticed that they (or some of them) also want to
> traverse (or get the attributes of /run/systemd/system)

On my system some services also want to send messages through
/run/systemd/notify unix socket.  I thus modified init_domain macro to
allow all its users to search /run/systemd and use notify, and as
/run/systemd/system has the same type as /run/systemd for now, I have
not (yet) noticed what you describe.  This part of my policy definitely
needs more work before I can submit a proper patch.

> Anyhow. I probably would keep this seperate from
> logging_send_syslog_msg()

All right.

> You might also be able to use a type attribute here
> 
> for example in systemd:
> 
> dontaudit parse_log_env_domain_type self:capability net_admin;
> kernel_read_system_state(parse_log_env_domain_type) 
> init_read_state(parse_log_env_domain_type)
> 
> Then just associate the type attribute with domain types that do the log
> env parsing
> 
> logging_send_syslog_msg (mydomain_t)
> 
> ifdef(`init_systemd',`
>     systemd_parse_log_env(mydomain_t)
> ')
> 
> or something...

I need to think more often of introducing attributes where it makes
sense, like here, thanks!  I will modify it in my policy, test it, and
send a v2 probably not before the week-end.

> In my personal dssp policy I just allowed all (journald) log clients to just read
> systemd state (my common domains can already read generic proc file by
> default) unconditionally. I also allowed log clients to traverse
> /run/systemd/system.
> 
> I basically use a different module for each log daemon instead of
> lumping then all together. It is up to the end-user do pick and choose
> the modules to use

As I am running Arch Linux, all programs from systemd are installed by
default.  It seems better for my usecase to have a policy for all of
these programs in one module, that I can avoid loading on my (still
existing) other non-systemd systems.

Anyway, thanks for your feedback!

Nicolas