From: dominick.grift@gmail.com (Dominick Grift)
Date: Tue, 08 Jul 2014 15:28:22 +0200
Subject: [refpolicy] [RFC] Add the security class and AV's needed for
 systemd
In-Reply-To: <20140708151648.65e6cdd8@soldur.bigon.be>
References: <1404568795-13434-1-git-send-email-bigon@debian.org>
	<1404568795-13434-2-git-send-email-bigon@debian.org>
	<53BBE468.8080901@tresys.com> <20140708151648.65e6cdd8@soldur.bigon.be>
Message-ID: <1404826102.19090.7.camel@x220.localdomain>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

On Tue, 2014-07-08 at 15:16 +0200, Laurent Bigonville wrote:
> Le Tue, 8 Jul 2014 08:30:32 -0400,
> "Christopher J. PeBenito" <cpebenito@tresys.com> a ?crit :
> 
> > On 7/5/2014 9:59 AM, Laurent Bigonville wrote:
> > > From: Laurent Bigonville <bigon@bigon.be>
> > > 
> > > The list of AV's has been built by grepping the systemd code for the
> > > calls to selinux_unit_access_check() and selinux_access_check()
> > > macro. ---
> > >  policy/flask/access_vectors      | 18 ++++++++++++++++++
> > >  policy/flask/security_classes    |  3 +++
> > >  policy/support/obj_perm_sets.spt |  5 +++++
> > >  3 files changed, 26 insertions(+)
> > > 
> > > diff --git a/policy/flask/access_vectors
> > > b/policy/flask/access_vectors index a94b169..e0d3768 100644
> > > --- a/policy/flask/access_vectors
> > > +++ b/policy/flask/access_vectors
> > > @@ -393,6 +393,14 @@ class system
> > >  	syslog_mod
> > >  	syslog_console
> > >  	module_request
> > > +	halt
> > > +	reboot
> > > +	status
> > > +	start
> > > +	stop
> > > +	enable
> > > +	disable
> > > +	reload
> > 
> > This doesn't look right.  There shouldn't be userspace permissions
> > mixed in with a kernel object class.  Are these really used or are
> > they compatibility for old versions of systemd?
> 
> I searched the code that is currently in the HEAD of the master branch
> in the systemd git repository and the code path still seems to be used
> ATM.
> 
> Dominick even had issue with the "start" AV not being associated to the
> system class when developing his own policy
> 
> > 
> > 
> > > @@ -865,3 +873,13 @@ inherits database
> > >  	implement
> > >  	execute
> > >  }
> > > +
> > > +class service
> > > +{
> > > +	start
> > > +	stop
> > > +	status
> > > +	reload
> > > +	enable
> > > +	disable
> > > +}
> > 
> 

Systemd has many issues with SELinux still, and it object managers in
core components in a system also exposes issues in libselinux.

Some of the issues:

1. systemd uses the linux system object for its some of it's access
vector permissions.
2. systemd creates objects on behalf of real users without setting
security contexts as specified in policy. (needs to use lsetfilecon)
3. systemd runs programs on behalf of real users without setting
security contexts as specified in policy. (needs to hook into
pam_selinux)
4. libselinux does not expose unknown user space access vectors. in the
past this has not proved to be a problem but now that core components
are object managers (systemd), and that dbus has become a core component
this proves to be a serious issue

These are some of the more pressing issues currently with systemd and
selinux. I have files bug reports for most of these issues (except issue
#1). However, i am having difficulties explaining what the problem is
here (or they have difficulties understanding or they just dont care).