As we move to systemd, we are loosing some functionality from init scripts.

As we move to systemd, we are loosing some functionality from init scripts.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Currently we can setup certain domains to be allowed to execute labeled
init scripts.  If we go away from init scripts we will need a mechanism
for init to look at the calling program label to figure out if it is
allowed to start/stop certain domains.

Can webadm_t start/stop mysqld_t?  Can webadm_t start/stop httpd_t?

# id -Z
staff_u:webadm_r:webadm_t:s0-s0:c0.c1023
# systemctl start httpd.service
# systemctl stop httpd.service

Another option would be just whether label
/lib/systemd/system/mysqld.service something that webadm_t is not
allowed to read.

Ideas?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4cuKUACgkQrlYvE4MpobMOygCg5fegKSSt82AuW6DtrS6GphDH
OPwAn0S6Y0+q4XFyqSBs2hIyrfgWlZ8o
=InWv
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: As we move to systemd, we are loosing some functionality from init scripts.

[Christopher J. PeBenito]

On 07/12/11 17:12, Daniel J Walsh wrote:
> Currently we can setup certain domains to be allowed to execute labeled
> init scripts.  If we go away from init scripts we will need a mechanism
> for init to look at the calling program label to figure out if it is
> allowed to start/stop certain domains.
> 
> Can webadm_t start/stop mysqld_t?  Can webadm_t start/stop httpd_t?
> 
> # id -Z
> staff_u:webadm_r:webadm_t:s0-s0:c0.c1023
> # systemctl start httpd.service
> # systemctl stop httpd.service
> 
> Another option would be just whether label
> /lib/systemd/system/mysqld.service something that webadm_t is not
> allowed to read.
> 
> Ideas?

Does your suggestion really make it impossible to send a command to
systemd to start/stop a service if you cant read that file (eg
mysqld.service)?  I don't know what the implementation is, but I would
guess that systemctl connects to systemd over a unix socket or fifo to
give commands?  If so, it would seem better for systemd to have some
SELinux awareness on its incoming commands.

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: As we move to systemd, we are loosing some functionality from init scripts.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/13/2011 09:33 AM, Christopher J. PeBenito wrote:
> On 07/12/11 17:12, Daniel J Walsh wrote:
>> Currently we can setup certain domains to be allowed to execute
>> labeled init scripts.  If we go away from init scripts we will need
>> a mechanism for init to look at the calling program label to figure
>> out if it is allowed to start/stop certain domains.
>> 
>> Can webadm_t start/stop mysqld_t?  Can webadm_t start/stop
>> httpd_t?
>> 
>> # id -Z staff_u:webadm_r:webadm_t:s0-s0:c0.c1023 # systemctl start
>> httpd.service # systemctl stop httpd.service
>> 
>> Another option would be just whether label 
>> /lib/systemd/system/mysqld.service something that webadm_t is not 
>> allowed to read.
>> 
>> Ideas?
> 
> Does your suggestion really make it impossible to send a command to 
> systemd to start/stop a service if you cant read that file (eg 
> mysqld.service)?  I don't know what the implementation is, but I
> would guess that systemctl connects to systemd over a unix socket or
> fifo to give commands?  If so, it would seem better for systemd to
> have some SELinux awareness on its incoming commands.
> 

I agree, but I am not sure of the syntax.

I was thinking that we might want systemd to ask if webadm_t is allowed
to execute /lib/systemd/system/mysqld.service, even though it is not
really executing the service script.  Since we do not know what is going
on in the service file, systemd will have a hard time differentiating
the access.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4dn+EACgkQrlYvE4MpobNEAwCgtHNdxRzaIVszkeEyic/jCN3a
HwMAnipcsLLpLLpKCTirCU1kFIWHM9fG
=APZx
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: As we move to systemd, we are loosing some functionality from init scripts.

[Matthew Ife]

I dont think that will work. According to my strace systemd performs the
work completely on behalf of the user when calling systemctl.

It might be more elegant to solve the problem in software.. ideally with
some selinux object manager for systemd that systemctl can be
intercepted with.

Say classes of target and service and permissions like start, stop
reload, restart etc.

That could take a while to implement though.

On Tue, 2011-07-12 at 17:12 -0400, Daniel J Walsh wrote:
> Currently we can setup certain domains to be allowed to execute labeled
> init scripts.  If we go away from init scripts we will need a mechanism
> for init to look at the calling program label to figure out if it is
> allowed to start/stop certain domains.
> 
> Can webadm_t start/stop mysqld_t?  Can webadm_t start/stop httpd_t?
> 
> # id -Z
> staff_u:webadm_r:webadm_t:s0-s0:c0.c1023
> # systemctl start httpd.service
> # systemctl stop httpd.service
> 
> Another option would be just whether label
> /lib/systemd/system/mysqld.service something that webadm_t is not
> allowed to read.
> 
> Ideas?
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.



--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: As we move to systemd, we are loosing some functionality from init scripts.

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 07/13/2011 01:20 PM, Matthew Ife wrote:
> I dont think that will work. According to my strace systemd performs
> the work completely on behalf of the user when calling systemctl.
> 
> It might be more elegant to solve the problem in software.. ideally
> with some selinux object manager for systemd that systemctl can be 
> intercepted with.
> 
> Say classes of target and service and permissions like start, stop 
> reload, restart etc.
> 
> That could take a while to implement though.
> 
Right, I was thinking of something simpler, Have systemd become an
object manager but only have it check the services file.  That way we
just put a label on the services file and have systemd check if the user
context is allowed to "PROCESS" "EXECUTE" or some other access method on
the services file.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4d2acACgkQrlYvE4MpobP1vwCeOKZ7Z15EU43/I7UN9i86Udcz
Qi0AoM71WDDl6Y1N3ZDNbdf/mRcKIWfT
=fDed
-----END PGP SIGNATURE-----

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: As we move to systemd, we are loosing some functionality from init scripts.

[Stephen Smalley]

On Wed, 2011-07-13 at 13:45 -0400, Daniel J Walsh wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 07/13/2011 01:20 PM, Matthew Ife wrote:
> > I dont think that will work. According to my strace systemd performs
> > the work completely on behalf of the user when calling systemctl.
> > 
> > It might be more elegant to solve the problem in software.. ideally
> > with some selinux object manager for systemd that systemctl can be 
> > intercepted with.
> > 
> > Say classes of target and service and permissions like start, stop 
> > reload, restart etc.
> > 
> > That could take a while to implement though.
> > 
> Right, I was thinking of something simpler, Have systemd become an
> object manager but only have it check the services file.  That way we
> just put a label on the services file and have systemd check if the user
> context is allowed to "PROCESS" "EXECUTE" or some other access method on
> the services file.

Don't reuse the kernel classes/permissions please.  I know we've done
that in e.g. crond in the past, but it conflates their purpose; define
new classes/perms for this purpose instead.  Also be sure to use the
newer interfaces for userspace object managers ala XSELinux so that you
use dynamic class/perm mapping.  We still need the older userspace
object managers to be updated in that regard.

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: As we move to systemd, we are loosing some functionality from init scripts.

[Russell Coker]

On Thu, 14 Jul 2011, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> Don't reuse the kernel classes/permissions please.  I know we've done
> that in e.g. crond in the past, but it conflates their purpose;

The crond operation is to ask the kernel what could happen if the crontab 
spool file was treated as an executable, and then apply the resulting context 
for executing the commands that it contains.

While this is not obvious to a SE Linux newbie, it makes sense and it closely 
matches the ancient crond code for checking UIDs for the Unix permission 
parts.

While making the operation more obvious to newbies does offer some benefits 
(including security benefits by avoiding mistakes), I can't think of a good 
way of achieving such a goal.

If we were to start from the Vixie-cron base and write entirely new SE Linux 
patches and policy without any legacy today how do you think we would do it 
better?

> define
> new classes/perms for this purpose instead.  Also be sure to use the
> newer interfaces for userspace object managers ala XSELinux so that you
> use dynamic class/perm mapping.  We still need the older userspace
> object managers to be updated in that regard.

systemd has to use labels on files for all variants of the proposed design so 
classes aren't an option.

Once we get role support in the filesystem code (how long will that take?) we 
could use role labels to determine which roles can execute the daemon start 
scripts.  But it would still surely end up with systemd just doing a check of 
whether the context of systemctl permits executing the /etc/init.d script in 
question.

-- 
My Main Blog         http://etbe.coker.com.au/
My Documents Blog    http://doc.coker.com.au/

--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: As we move to systemd, we are loosing some functionality from init scripts.

[Stephen Smalley]

On Thu, 2011-07-14 at 23:23 +1000, Russell Coker wrote:
> On Thu, 14 Jul 2011, Stephen Smalley <sds@tycho.nsa.gov> wrote:
> > Don't reuse the kernel classes/permissions please.  I know we've done
> > that in e.g. crond in the past, but it conflates their purpose;
> 
> The crond operation is to ask the kernel what could happen if the crontab 
> spool file was treated as an executable, and then apply the resulting context 
> for executing the commands that it contains.

Yes, IIRC, that was my idea.

> While this is not obvious to a SE Linux newbie, it makes sense and it closely 
> matches the ancient crond code for checking UIDs for the Unix permission 
> parts.
> 
> While making the operation more obvious to newbies does offer some benefits 
> (including security benefits by avoiding mistakes), I can't think of a good 
> way of achieving such a goal.
> 
> If we were to start from the Vixie-cron base and write entirely new SE Linux 
> patches and policy without any legacy today how do you think we would do it 
> better?

In retrospect, I think it would have been cleaner to have defined a
unique class/perm for this purpose.  Both in order to cleanly delineate
the kernel classes/permissions from userspace ones and to make clear the
semantic difference between an execve of a file and running a cron job
from a configuration file.

> systemd has to use labels on files for all variants of the proposed design so 
> classes aren't an option.

It is fine for systemd to use a file label as the object security
context if that is the granularity at which we want to control the
operations, but systemd can still define and use its own classes and
permissions for the permission checks on its operations.  In a similar
manner, dbusd is using the security context of the destination process
as the object security context for its check, yet it defines its own
class and permissions for those checks.  And of course all of the
userspace object managers are using the process context as the
subject/source context.

> Once we get role support in the filesystem code (how long will that take?) we 
> could use role labels to determine which roles can execute the daemon start 
> scripts.  But it would still surely end up with systemd just doing a check of 
> whether the context of systemctl permits executing the /etc/init.d script in 
> question.
> 

-- 
Stephen Smalley
National Security Agency


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: As we move to systemd, we are loosing some functionality from init scripts.

[Daniel J Walsh]

[-- Attachment #1: Type: text/plain, Size: 402 bytes --]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I guess we can add something like the attached, and then implement
systemd checks on these.

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk4gdHEACgkQrlYvE4MpobOg3gCfU23GCTQuktksXCu6j2mGdnh0
TRUAnRRo34V3/OIxe+ikn7mFrI3sLy38
=gJiT
-----END PGP SIGNATURE-----

[-- Attachment #2: service.diff --]
[-- Type: text/x-patch, Size: 637 bytes --]

diff --git a/policy/flask/access_vectors b/policy/flask/access_vectors
index bf24160..468e0fd 100644
--- a/policy/flask/access_vectors
+++ b/policy/flask/access_vectors
@@ -862,3 +862,12 @@ inherits database
 	implement
 	execute
 }
+
+class service
+{
+	start
+	stop
+	status
+	reload
+	kill
+}
diff --git a/policy/flask/security_classes b/policy/flask/security_classes
index 14a4799..067ecfc 100644
--- a/policy/flask/security_classes
+++ b/policy/flask/security_classes
@@ -131,4 +131,8 @@ class db_view			# userspace
 class db_sequence		# userspace
 class db_language		# userspace
 
+# systemd services 
+class service 
+
+
 # FLASK

[-- Attachment #3: service.diff.sig --]
[-- Type: application/pgp-signature, Size: 72 bytes --]