From: dac.override@gmail.com (Dominick Grift) Date: Tue, 12 Jan 2016 09:29:55 +0100 Subject: [refpolicy] [RFC PATCH] Add an interface for systemd services logging config In-Reply-To: <56942775.6050901@m4x.org> References: <1452539261-17628-1-git-send-email-nicolas.iooss@m4x.org> <20160111204111.GA15886@x250> <56942775.6050901@m4x.org> Message-ID: <20160112082954.GA14597@x250> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----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-----