[refpolicy] [RFC PATCH] Add an interface for systemd services logging config

[dac.override@gmail.com (Dominick Grift)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

On Mon, Jan 11, 2016 at 11:06:45PM +0100, Nicolas Iooss wrote:
> 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.).


I did not have the "init_read_state($1)" as part of my "logging" macro,
and just yesterday i started confining gnome-session and it wanted to
log to journal. It needed to read systemd state as well.

Thus i suspect that gnome-session is one of the services that falls into
this category.

> 
> > 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.

The notify socket is for
http://www.freedesktop.org/software/systemd/man/sd_notify.html i
believe.

I have a seperate macro for that sd.notify_client_subj_type() (or
something along those lines)

I suspect that the traversing of /run/systemd/system is not related to
notify clients. since that location is for runtime units only

processes that log seems of something want to at least get the attribute
of /run/systemd/system , but also systemctl seems to have this requirement.
> 
> > 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.
>

Yes, there are considerations though. it is not always a good idea and this is a corner case

Remember that the selinux policy language does not allow you to
associate type attributes with type attributes (unlike CIL), so with the
example above something like: systemd_parse_log_env(application_domain),
will not work. Since that would require that you associate
application_domain with parse_log_env_domain_type.


> > 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.
>

I understand this sentiment, but systemd is supposed to be modular, just
because you have for example systemd-nspawn/machined installed does not
mean you have to use it, same goes for other components.

There is this ongoing urge in some distributions to rethink how its
packaged, but a few people are opposed to it.

The issue i see with this approach of consolidation is that it sets a
precedent, and when all said and done because of all these little
compromises the policy ends up much less customizable/modular, and
modules are not as tailored as the could be.

To what end? Just so that users do not have to profile anymore?

well that is working because i know of very little people that actually
take time to do profiling and customize their collection of modules when
they enable selinux. (and i do not think that is neccesarily a good thing)

> Anyway, thanks for your feedback!
> 
> Nicolas
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy

- -- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCAAGBQJWlLl+AAoJECV0jlU3+UdpYAcL/R15Ui4XoVg/Z5KFF8H76iyu
+1Ipa+MRb2eyyqvr8i2c22qtt+LiToDjwzb8YbtLIpyDW4/UqzcdnTvAtE9SbiIZ
0sI/7XjSOUyeKgmNk8Rom00RCKAaUF/lGxrlAvbNb8ZEmnvYlQT2xAAHRHm+PmCT
upFkVDFJGr6o26t56YUJujncTvIelwpbLflvJpbODia/J1lD4fuRTS2dxVVWPQBp
QmT4wFjfxMLgB3Zzm5RuyeShhrR1A/gSFSIztSaTUUusykxjkHxGrcIxMyjtbCMD
a3Q9gmedwEs6xW+V9y1HC6ABURwgB2mNShwk3XJdX8FLkOJ2Zb53dMceWZLrelyd
harOeDA3spWNl442fFq6vveHaV5p4pu6YVm1/0irOiOoxAtn5V1S98HorhRsIE84
5BL1zW7IFKcYac8nGkKparQdh/X4A3fPm12wpAFjXPZHA1ZbImXVWhe4vBtaCbJb
K9NrlXsosCVmhnJ+rPtbIh/gPsSINzMPek6jOWZV+Q==
=ONov
-----END PGP SIGNATURE-----