(Userspace) AVC denial generated even if allowed by the policy?

(Userspace) AVC denial generated even if allowed by the policy?

[Laurent Bigonville]

Hi,

I'm still looking at adding SELinux support in the "at" daemon and I now 
have the following patch[0].

With this patch, at seems to behave like the cron daemon, as explained 
in the commit log:

     - When cron_userdomain_transition is set to off, a process for an
       unconfined user will transition to unconfined_cronjob_t. For confined
       user, the job is run as cronjob_t.

     - When cron_userdomain_transition is set to on, the processes are run
       under the user default context.

But every time an AVC denial is generated (with 
cron_userdomain_transition set to off and the user running as staff_u, 
in permissive with unmodified refpolicy):

avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0 
tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file

The job runs as (id -Z): staff_u:staff_r:cronjob_t:s0

But audit2{allow,why} are saying that this is already allowed in the policy

Setting the cron_userdomain_transition boolean to on, I have the 
following avc:

avc:  denied  { entrypoint } for scontext=staff_u:sysadm_r:sysadm_t:s0 
tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file

The job runs as (id -Z): staff_u:sysadm_r:sysadm_t:s0

So as said it seems to work, but I'm not sure why this AVC denial is 
generated.

sesearch shows:

$ sesearch -ATSC  -t user_cron_spool_t -c file -p entrypoint
Found 6 semantic av rules:
    allow files_unconfined_type file_type : file { ioctl read write 
create getattr setattr lock relabelfrom relabelto append unlink link 
rename execute swapon quotaon mounton execute_no_trans entrypoint open 
audit_access } ;
DT allow unconfined_t user_cron_spool_t : file entrypoint ; [ 
cron_userdomain_transition ]
DT allow user_t user_cron_spool_t : file entrypoint ; [ 
cron_userdomain_transition ]
EF allow cronjob_t user_cron_spool_t : file entrypoint ; [ 
cron_userdomain_transition ]
DT allow staff_t user_cron_spool_t : file entrypoint ; [ 
cron_userdomain_transition ]
DT allow sysadm_t user_cron_spool_t : file entrypoint ; [ 
cron_userdomain_transition ]

Did I overlooked something?

Cheers,

Laurent Bigonville

[0] 
https://anonscm.debian.org/cgit/users/bigon/at.git/commit/?h=selinux&id=0112f006b74a36f7200e315575fd25d78e11b170 

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On Mon, Nov 23, 2015 at 01:53:03AM +0100, Laurent Bigonville wrote:
> Hi,
> 
> I'm still looking at adding SELinux support in the "at" daemon and I now
> have the following patch[0].
> 
> With this patch, at seems to behave like the cron daemon, as explained in
> the commit log:
> 
>     - When cron_userdomain_transition is set to off, a process for an
>       unconfined user will transition to unconfined_cronjob_t. For confined
>       user, the job is run as cronjob_t.
> 
>     - When cron_userdomain_transition is set to on, the processes are run
>       under the user default context.
> 
> But every time an AVC denial is generated (with cron_userdomain_transition
> set to off and the user running as staff_u, in permissive with unmodified
> refpolicy):
> 
> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
> 
> The job runs as (id -Z): staff_u:staff_r:cronjob_t:s0
> 
> But audit2{allow,why} are saying that this is already allowed in the policy
> 
> Setting the cron_userdomain_transition boolean to on, I have the following
> avc:
> 
> avc:  denied  { entrypoint } for scontext=staff_u:sysadm_r:sysadm_t:s0
> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file

I think this is weird as well since user_cron_spool_t is not actually
executed as far as i know (and thus is not actually an entrypoint). The entrypoint permission is merely allowed so
that crond_t/atd_t can calculate access to the target domains.

So i do not see why these entrypoint events are hit in the first place

> 
> The job runs as (id -Z): staff_u:sysadm_r:sysadm_t:s0
> 
> So as said it seems to work, but I'm not sure why this AVC denial is
> generated.
> 
> sesearch shows:
> 
> $ sesearch -ATSC  -t user_cron_spool_t -c file -p entrypoint
> Found 6 semantic av rules:
>    allow files_unconfined_type file_type : file { ioctl read write create
> getattr setattr lock relabelfrom relabelto append unlink link rename execute
> swapon quotaon mounton execute_no_trans entrypoint open audit_access } ;
> DT allow unconfined_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow user_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> EF allow cronjob_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow staff_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow sysadm_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> 
> Did I overlooked something?
> 
> Cheers,
> 
> Laurent Bigonville
> 
> [0] https://anonscm.debian.org/cgit/users/bigon/at.git/commit/?h=selinux&id=0112f006b74a36f7200e315575fd25d78e11b170
> 
> _______________________________________________
> Selinux mailing list
> Selinux@tycho.nsa.gov
> To unsubscribe, send email to Selinux-leave@tycho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@tycho.nsa.gov.

- -- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
https://sks-keyservers.net/pks/lookup?op=get&search=0x314883A202DFF788
Dominick Grift
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQGcBAEBCgAGBQJWUsliAAoJENAR6kfG5xmceAcL/jHlL/Ru8AeJ0kciGQoBfNHQ
KszDv3fv5x3l1qlN9311Do8mnjVedZS+7fucA+AaXT1R/EpSdVlZZsf5fXaIhPc3
k28niDSGIWrLypLsjlEbkZ/KgIZNuMOnmIVmfuhakVlyZmdq/VFmd6wQb1xuIoet
ZrPclGtiXbKljkKbXTlMWEioMf1mM1CRUWuekZu2ViGWbBRCAOvl+qbWQzRgW5Xy
QWk4U29wXLHlhr3UYIdiZcR7avprY3e6xhb+KmL6Q7smfuIsV8iLT3qIy1r/9nLb
cotbilVVnBdJYZxuTqZxe7nZpCl2tY9ScYtgarljqBWanOG1Qt8jPLgIVdyXDYZs
64vfPoBuAj/XaKxoiffm3U4xuMSfQOJKkEA0VGWjvz2P2f9qWXw5Qwrfb6IxQKkP
TjAB+E1kauzvrVzXaw1vbgYOfrggcl4dGoSaA347C4KxAa/BXh76Cj23DfWeF82P
799SMSSzLZQGQKCOhArW7I0ZwFSRAXQtaX2LqH11Yw==
=g861
-----END PGP SIGNATURE-----

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Laurent Bigonville]

Le 23/11/15 09:08, Dominick Grift a écrit :
> On Mon, Nov 23, 2015 at 01:53:03AM +0100, Laurent Bigonville wrote:
>> Hi,
>>
>> I'm still looking at adding SELinux support in the "at" daemon and I now
>> have the following patch[0].
>>
>> With this patch, at seems to behave like the cron daemon, as explained in
>> the commit log:
>>
>>      - When cron_userdomain_transition is set to off, a process for an
>>        unconfined user will transition to unconfined_cronjob_t. For confined
>>        user, the job is run as cronjob_t.
>>
>>      - When cron_userdomain_transition is set to on, the processes are run
>>        under the user default context.
>>
>> But every time an AVC denial is generated (with cron_userdomain_transition
>> set to off and the user running as staff_u, in permissive with unmodified
>> refpolicy):
>>
>> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
>> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>>
>> The job runs as (id -Z): staff_u:staff_r:cronjob_t:s0
>>
>> But audit2{allow,why} are saying that this is already allowed in the policy
>>
>> Setting the cron_userdomain_transition boolean to on, I have the following
>> avc:
>>
>> avc:  denied  { entrypoint } for scontext=staff_u:sysadm_r:sysadm_t:s0
>> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
> I think this is weird as well since user_cron_spool_t is not actually
> executed as far as i know (and thus is not actually an entrypoint). The entrypoint permission is merely allowed so
> that crond_t/atd_t can calculate access to the target domains.
>
> So i do not see why these entrypoint events are hit in the first place

The code is explicitly doing that, I guess it's the design decision from 
the original writer of the patch:

  /*
  * Since crontab files are not directly executed,
  * crond must ensure that the crontab file has
  * a context that is appropriate for the context of
  * the user cron job. It performs an entrypoint
  * permission check for this purpose.
  */

And that's why there is a entrypoint check:

selinux_check_access(user_context, file_context, "file", "entrypoint", 
NULL);

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Laurent Bigonville]

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

Le 23/11/15 01:53, Laurent Bigonville a écrit :
> Hi,
>
> I'm still looking at adding SELinux support in the "at" daemon and I
> now have the following patch[0].
>
> With this patch, at seems to behave like the cron daemon, as explained
> in the commit log:
>
>     - When cron_userdomain_transition is set to off, a process for an
>       unconfined user will transition to unconfined_cronjob_t. For
> confined
>       user, the job is run as cronjob_t.
>
>     - When cron_userdomain_transition is set to on, the processes are run
>       under the user default context.
>
> But every time an AVC denial is generated (with
> cron_userdomain_transition set to off and the user running as staff_u,
> in permissive with unmodified refpolicy):
>
> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>
> The job runs as (id -Z): staff_u:staff_r:cronjob_t:s0
>
> But audit2{allow,why} are saying that this is already allowed in the
> policy
>
> Setting the cron_userdomain_transition boolean to on, I have the
> following avc:
>
> avc:  denied  { entrypoint } for scontext=staff_u:sysadm_r:sysadm_t:s0
> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>
> The job runs as (id -Z): staff_u:sysadm_r:sysadm_t:s0
>
> So as said it seems to work, but I'm not sure why this AVC denial is
> generated.
>
> sesearch shows:
>
> $ sesearch -ATSC  -t user_cron_spool_t -c file -p entrypoint
> Found 6 semantic av rules:
>    allow files_unconfined_type file_type : file { ioctl read write
> create getattr setattr lock relabelfrom relabelto append unlink link
> rename execute swapon quotaon mounton execute_no_trans entrypoint open
> audit_access } ;
> DT allow unconfined_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow user_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> EF allow cronjob_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow staff_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow sysadm_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
>
> Did I overlooked something?
>
> Cheers,
>
> Laurent Bigonville
>
> [0]
> https://anonscm.debian.org/cgit/users/bigon/at.git/commit/?h=selinux&id=0112f006b74a36f7200e315575fd25d78e11b170

I'm attaching the patch to this mail for the people that cannot access
the website and FTR.

Cheers,

Laurent Bigonville


[-- Attachment #2: 0001-Allow-the-user-cronjobs-to-run-in-their-userdomain.patch --]
[-- Type: text/x-patch, Size: 4973 bytes --]

>From c8aa69e51d8781da782a50dbdf20b258288093d4 Mon Sep 17 00:00:00 2001
From: Laurent Bigonville <bigon@bigon.be>
Date: Mon, 23 Nov 2015 12:25:13 +0100
Subject: [PATCH] Allow the user cronjobs to run in their userdomain

When cron_userdomain_transition boolean is set to on, the user cronjobs
are supposed to run in their domains. Without this patch the default
context is not properly computed:

    $ /usr/sbin/getdefaultcon user_u system_u:system_r:crond_t:s0
    /usr/sbin/getdefaultcon: Invalid argument
    $ /usr/sbin/getdefaultcon staff_u system_u:system_r:crond_t:s0
    staff_u:sysadm_r:sysadm_t:s0

With this patch applied:

    $ /usr/sbin/getdefaultcon user_u system_u:system_r:crond_t:s0
    user_u:user_r:user_t:s0
    $ /usr/sbin/getdefaultcon staff_ system_u:system_r:crond_t:s0
    staff_u:staff_r:staff_t:s0
---
 config/appconfig-mcs/staff_u_default_contexts      | 2 +-
 config/appconfig-mcs/user_u_default_contexts       | 2 +-
 config/appconfig-mls/staff_u_default_contexts      | 2 +-
 config/appconfig-mls/user_u_default_contexts       | 2 +-
 config/appconfig-standard/staff_u_default_contexts | 2 +-
 config/appconfig-standard/user_u_default_contexts  | 2 +-
 6 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/config/appconfig-mcs/staff_u_default_contexts b/config/appconfig-mcs/staff_u_default_contexts
index 881a292..5606c4e 100644
--- a/config/appconfig-mcs/staff_u_default_contexts
+++ b/config/appconfig-mcs/staff_u_default_contexts
@@ -1,7 +1,7 @@
 system_r:local_login_t:s0	staff_r:staff_t:s0 sysadm_r:sysadm_t:s0
 system_r:remote_login_t:s0	staff_r:staff_t:s0
 system_r:sshd_t:s0		staff_r:staff_t:s0 sysadm_r:sysadm_t:s0
-system_r:crond_t:s0		staff_r:cronjob_t:s0
+system_r:crond_t:s0		staff_r:staff_t:s0 staff_r:cronjob_t:s0
 system_r:xdm_t:s0		staff_r:staff_t:s0
 staff_r:staff_su_t:s0		staff_r:staff_t:s0
 staff_r:staff_sudo_t:s0		staff_r:staff_t:s0
diff --git a/config/appconfig-mcs/user_u_default_contexts b/config/appconfig-mcs/user_u_default_contexts
index cacbc93..56d6071 100644
--- a/config/appconfig-mcs/user_u_default_contexts
+++ b/config/appconfig-mcs/user_u_default_contexts
@@ -1,7 +1,7 @@
 system_r:local_login_t:s0	user_r:user_t:s0
 system_r:remote_login_t:s0	user_r:user_t:s0
 system_r:sshd_t:s0		user_r:user_t:s0
-system_r:crond_t:s0		user_r:cronjob_t:s0
+system_r:crond_t:s0		user_r:user_t:s0 user_r:cronjob_t:s0
 system_r:xdm_t:s0		user_r:user_t:s0
 user_r:user_su_t:s0		user_r:user_t:s0
 user_r:user_sudo_t:s0		user_r:user_t:s0
diff --git a/config/appconfig-mls/staff_u_default_contexts b/config/appconfig-mls/staff_u_default_contexts
index 881a292..5606c4e 100644
--- a/config/appconfig-mls/staff_u_default_contexts
+++ b/config/appconfig-mls/staff_u_default_contexts
@@ -1,7 +1,7 @@
 system_r:local_login_t:s0	staff_r:staff_t:s0 sysadm_r:sysadm_t:s0
 system_r:remote_login_t:s0	staff_r:staff_t:s0
 system_r:sshd_t:s0		staff_r:staff_t:s0 sysadm_r:sysadm_t:s0
-system_r:crond_t:s0		staff_r:cronjob_t:s0
+system_r:crond_t:s0		staff_r:staff_t:s0 staff_r:cronjob_t:s0
 system_r:xdm_t:s0		staff_r:staff_t:s0
 staff_r:staff_su_t:s0		staff_r:staff_t:s0
 staff_r:staff_sudo_t:s0		staff_r:staff_t:s0
diff --git a/config/appconfig-mls/user_u_default_contexts b/config/appconfig-mls/user_u_default_contexts
index cacbc93..56d6071 100644
--- a/config/appconfig-mls/user_u_default_contexts
+++ b/config/appconfig-mls/user_u_default_contexts
@@ -1,7 +1,7 @@
 system_r:local_login_t:s0	user_r:user_t:s0
 system_r:remote_login_t:s0	user_r:user_t:s0
 system_r:sshd_t:s0		user_r:user_t:s0
-system_r:crond_t:s0		user_r:cronjob_t:s0
+system_r:crond_t:s0		user_r:user_t:s0 user_r:cronjob_t:s0
 system_r:xdm_t:s0		user_r:user_t:s0
 user_r:user_su_t:s0		user_r:user_t:s0
 user_r:user_sudo_t:s0		user_r:user_t:s0
diff --git a/config/appconfig-standard/staff_u_default_contexts b/config/appconfig-standard/staff_u_default_contexts
index c2a5ea8..300694c 100644
--- a/config/appconfig-standard/staff_u_default_contexts
+++ b/config/appconfig-standard/staff_u_default_contexts
@@ -1,7 +1,7 @@
 system_r:local_login_t		staff_r:staff_t sysadm_r:sysadm_t
 system_r:remote_login_t		staff_r:staff_t
 system_r:sshd_t			staff_r:staff_t sysadm_r:sysadm_t
-system_r:crond_t		staff_r:cronjob_t
+system_r:crond_t		staff_r:staff_t staff_r:cronjob_t
 system_r:xdm_t			staff_r:staff_t
 staff_r:staff_su_t		staff_r:staff_t
 staff_r:staff_sudo_t		staff_r:staff_t
diff --git a/config/appconfig-standard/user_u_default_contexts b/config/appconfig-standard/user_u_default_contexts
index f5bfac3..63b7eec 100644
--- a/config/appconfig-standard/user_u_default_contexts
+++ b/config/appconfig-standard/user_u_default_contexts
@@ -1,7 +1,7 @@
 system_r:local_login_t		user_r:user_t
 system_r:remote_login_t		user_r:user_t
 system_r:sshd_t			user_r:user_t
-system_r:crond_t		user_r:cronjob_t
+system_r:crond_t		user_r:user_t user_r:cronjob_t
 system_r:xdm_t			user_r:user_t
 user_r:user_su_t		user_r:user_t
 user_r:user_sudo_t		user_r:user_t
-- 
2.6.2

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Laurent Bigonville]

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

Le 23/11/15 16:34, Laurent Bigonville a écrit :
> Le 23/11/15 01:53, Laurent Bigonville a écrit :
>> Hi,
>>
>> I'm still looking at adding SELinux support in the "at" daemon and I
>> now have the following patch[0].
>>
>> With this patch, at seems to behave like the cron daemon, as
>> explained in the commit log:
>>
>>     - When cron_userdomain_transition is set to off, a process for an
>>       unconfined user will transition to unconfined_cronjob_t. For
>> confined
>>       user, the job is run as cronjob_t.
>>
>>     - When cron_userdomain_transition is set to on, the processes are
>> run
>>       under the user default context.
>>
>> But every time an AVC denial is generated (with
>> cron_userdomain_transition set to off and the user running as
>> staff_u, in permissive with unmodified refpolicy):
>>
>> avc:  denied  { entrypoint } for
>> scontext=staff_u:staff_r:cronjob_t:s0
>> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>>
>> The job runs as (id -Z): staff_u:staff_r:cronjob_t:s0
>>
>> But audit2{allow,why} are saying that this is already allowed in the
>> policy
>>
>> Setting the cron_userdomain_transition boolean to on, I have the
>> following avc:
>>
>> avc:  denied  { entrypoint } for
>> scontext=staff_u:sysadm_r:sysadm_t:s0
>> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>>
>> The job runs as (id -Z): staff_u:sysadm_r:sysadm_t:s0
>>
>> So as said it seems to work, but I'm not sure why this AVC denial is
>> generated.
>>
>> sesearch shows:
>>
>> $ sesearch -ATSC  -t user_cron_spool_t -c file -p entrypoint
>> Found 6 semantic av rules:
>>    allow files_unconfined_type file_type : file { ioctl read write
>> create getattr setattr lock relabelfrom relabelto append unlink link
>> rename execute swapon quotaon mounton execute_no_trans entrypoint
>> open audit_access } ;
>> DT allow unconfined_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>> DT allow user_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>> EF allow cronjob_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>> DT allow staff_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>> DT allow sysadm_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>>
>> Did I overlooked something?
>>
>> Cheers,
>>
>> Laurent Bigonville
>>
>> [0]
>> https://anonscm.debian.org/cgit/users/bigon/at.git/commit/?h=selinux&id=0112f006b74a36f7200e315575fd25d78e11b170
>
> I'm attaching the patch to this mail for the people that cannot access
> the website and FTR.
And it was of course the wrong one...


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Add-SELinux-support-to-run-jobs-in-the-proper-domain.patch --]
[-- Type: text/x-patch; name="0001-Add-SELinux-support-to-run-jobs-in-the-proper-domain.patch", Size: 6837 bytes --]

>From 0112f006b74a36f7200e315575fd25d78e11b170 Mon Sep 17 00:00:00 2001
From: Laurent Bigonville <bigon@bigon.be>
Date: Thu, 16 Jul 2015 01:06:06 +0200
Subject: [PATCH] Add SELinux support to run jobs in the proper domain
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Currently, jobs run by at are run in the crond_t domain and not
transitioned outside of it.

With this patch, the jobs are transitioned in the same domain as the
jobs that are run by the cron daemon:

- When cron_userdomain_transition is set to off, a process for an
  unconfined user will transition to unconfined_cronjob_t. For confined
  user, the job is run as cronjob_t.

- When cron_userdomain_transition is set to on, the processes are run
  under the user default context.

This patch is based on Marcela Mašláňová <mmaslano@redhat.com> work
---
 Makefile.in  |  3 ++-
 atd.c        | 87 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 config.h.in  |  3 +++
 configure.ac |  8 ++++++
 daemon.c     | 16 +++++++++++
 daemon.h     |  3 +++
 6 files changed, 119 insertions(+), 1 deletion(-)

diff --git a/Makefile.in b/Makefile.in
index 06544f9..dd3c2f8 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -40,6 +40,7 @@ LIBS		= @LIBS@
 LIBOBJS		= @LIBOBJS@
 INSTALL		= @INSTALL@
 PAMLIB          = @PAMLIB@
+SELINUXLIB      = @SELINUXLIB@

 CLONES		= atq atrm
 ATOBJECTS	= at.o panic.o perm.o posixtm.o y.tab.o lex.yy.o
@@ -73,7 +74,7 @@ at: $(ATOBJECTS)
 	$(LN_S) -f at atrm

 atd: $(RUNOBJECTS)
-	$(CC) $(LDFLAGS) -o atd $(RUNOBJECTS) $(LIBS) $(PAMLIB)
+	$(CC) $(LDFLAGS) -o atd $(RUNOBJECTS) $(LIBS) $(PAMLIB) $(SELINUXLIB)

 y.tab.c y.tab.h: parsetime.y
 	$(YACC) -d parsetime.y
diff --git a/atd.c b/atd.c
index d0b422e..abb860e 100644
--- a/atd.c
+++ b/atd.c
@@ -83,6 +83,12 @@
 #include "getloadavg.h"
 #endif

+#ifdef WITH_SELINUX
+#include <selinux/selinux.h>
+#include <selinux/get_context_list.h>
+int selinux_enabled = 0;
+#endif
+
 /* Macros */

 #define BATCH_INTERVAL_DEFAULT 60
@@ -195,6 +201,72 @@ myfork()
 #define fork myfork
 #endif

+#ifdef WITH_SELINUX
+static int
+set_selinux_context(const char *name, const char *filename) {
+    security_context_t user_context = NULL;
+    security_context_t file_context = NULL;
+    int retval = 0;
+    char *seuser = NULL;
+    char *level = NULL;
+
+    if (getseuserbyname(name, &seuser, &level) == 0) {
+        retval = get_default_context_with_level(seuser, level, NULL, &user_context);
+        free(seuser);
+        free(level);
+        if (retval < 0) {
+            lerr("get_default_context_with_level: couldn't get security context for user %s", name);
+            retval = -1;
+            goto err;
+        }
+    }
+
+    /*
+     * Since crontab files are not directly executed,
+     * crond must ensure that the crontab file has
+     * a context that is appropriate for the context of
+     * the user cron job.  It performs an entrypoint
+     * permission check for this purpose.
+     */
+    if (fgetfilecon(STDIN_FILENO, &file_context) < 0) {
+        lerr("fgetfilecon FAILED %s", filename);
+        retval = -1;
+        goto err;
+    }
+
+    retval = selinux_check_access(user_context, file_context, "file", "entrypoint", NULL);
+    freecon(file_context);
+    if (retval < 0) {
+        lerr("Not allowed to set exec context to %s for user  %s", user_context, name);
+        retval = -1;
+        goto err;
+    }
+    if (setexeccon(user_context) < 0) {
+        lerr("Could not set exec context to %s for user  %s", user_context, name);
+        retval = -1;
+        goto err;
+    }
+err:
+    if (retval < 0 && security_getenforce() != 1)
+        retval = 0;
+    if (user_context)
+        freecon(user_context);
+    return retval;
+}
+
+static int
+selinux_log_callback (int type, const char *fmt, ...)
+{
+    va_list ap;
+
+    va_start(ap, fmt);
+    vsyslog (LOG_ERR, fmt, ap);
+    va_end(ap);
+    return 0;
+}
+
+#endif
+
 static void
 run_file(const char *filename, uid_t uid, gid_t gid)
 {
@@ -424,6 +496,13 @@ run_file(const char *filename, uid_t uid, gid_t gid)

 	    nice((tolower((int) queue) - 'a' + 1) * 2);

+#ifdef WITH_SELINUX
+	    if (selinux_enabled > 0) {
+	        if (set_selinux_context(pentry->pw_name, filename) < 0)
+	            perr("SELinux Failed to set context\n");
+	    }
+#endif
+
 	    if (initgroups(pentry->pw_name, pentry->pw_gid))
 		perr("Cannot initialize the supplementary group access list");

@@ -707,6 +786,14 @@ main(int argc, char *argv[])
     struct passwd *pwe;
     struct group *ge;

+#ifdef WITH_SELINUX
+    selinux_enabled=is_selinux_enabled();
+
+    if (selinux_enabled) {
+        selinux_set_callback(SELINUX_CB_LOG, (union selinux_callback) selinux_log_callback);
+    }
+#endif
+
 /* We don't need root privileges all the time; running under uid and gid
  * daemon is fine.
  */
diff --git a/config.h.in b/config.h.in
index 4d7dc91..681d68e 100644
--- a/config.h.in
+++ b/config.h.in
@@ -192,6 +192,9 @@
    <sys/cpustats.h>. */
 #undef UMAX4_3

+/* Define if you are building with_selinux */
+#undef WITH_SELINUX
+
 /* Define to 1 if `lex' declares `yytext' as a `char *' by default, not a
    `char[]'. */
 #undef YYTEXT_POINTER
diff --git a/configure.ac b/configure.ac
index bcd3ec6..0321a02 100644
--- a/configure.ac
+++ b/configure.ac
@@ -239,6 +239,14 @@ AC_ARG_WITH(daemon_username,
 )
 AC_SUBST(DAEMON_USERNAME)

+AC_ARG_WITH(selinux,
+[ --with-selinux       Define to run with selinux],
+AC_DEFINE(WITH_SELINUX, 1, [Define if you are building with_selinux]),
+)
+AC_CHECK_LIB(selinux, is_selinux_enabled, SELINUXLIB=-lselinux)
+AC_SUBST(SELINUXLIB)
+AC_SUBST(WITH_SELINUX)
+
 AC_MSG_CHECKING(groupname to run under)
 AC_ARG_WITH(daemon_groupname,
 [ --with-daemon_groupname=DAEMON_GROUPNAME	Groupname to run under (default daemon) ],
diff --git a/daemon.c b/daemon.c
index 8be40d4..f9d25e7 100644
--- a/daemon.c
+++ b/daemon.c
@@ -83,6 +83,22 @@ perr(const char *fmt,...)
 }

 void
+lerr(const char *fmt,...)
+{
+    char buf[1024];
+    va_list args;
+
+    va_start(args, fmt);
+    vsnprintf(buf, sizeof(buf), fmt, args);
+    va_end(args);
+
+    if (daemon_debug) {
+	perror(buf);
+    } else
+	syslog(LOG_ERR, "%s: %m", buf);
+}
+
+void
 pabort(const char *fmt,...)
 {
     char buf[1024];
diff --git a/daemon.h b/daemon.h
index c4507ae..f44ccd1 100644
--- a/daemon.h
+++ b/daemon.h
@@ -13,5 +13,8 @@ __attribute__((noreturn))
 #endif
 perr (const char *fmt, ...);

+void
+lerr (const char *fmt, ...);
+
 extern int daemon_debug;
 extern int daemon_foreground;
--
2.6.2

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Stephen Smalley]

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

On 11/22/2015 07:53 PM, Laurent Bigonville wrote:
> Hi,
>
> I'm still looking at adding SELinux support in the "at" daemon and I now
> have the following patch[0].
>
> With this patch, at seems to behave like the cron daemon, as explained
> in the commit log:
>
>      - When cron_userdomain_transition is set to off, a process for an
>        unconfined user will transition to unconfined_cronjob_t. For
> confined
>        user, the job is run as cronjob_t.
>
>      - When cron_userdomain_transition is set to on, the processes are run
>        under the user default context.
>
> But every time an AVC denial is generated (with
> cron_userdomain_transition set to off and the user running as staff_u,
> in permissive with unmodified refpolicy):
>
> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>
> The job runs as (id -Z): staff_u:staff_r:cronjob_t:s0
>
> But audit2{allow,why} are saying that this is already allowed in the policy
>
> Setting the cron_userdomain_transition boolean to on, I have the
> following avc:
>
> avc:  denied  { entrypoint } for scontext=staff_u:sysadm_r:sysadm_t:s0
> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>
> The job runs as (id -Z): staff_u:sysadm_r:sysadm_t:s0
>
> So as said it seems to work, but I'm not sure why this AVC denial is
> generated.
>
> sesearch shows:
>
> $ sesearch -ATSC  -t user_cron_spool_t -c file -p entrypoint
> Found 6 semantic av rules:
>     allow files_unconfined_type file_type : file { ioctl read write
> create getattr setattr lock relabelfrom relabelto append unlink link
> rename execute swapon quotaon mounton execute_no_trans entrypoint open
> audit_access } ;
> DT allow unconfined_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow user_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> EF allow cronjob_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow staff_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
> DT allow sysadm_t user_cron_spool_t : file entrypoint ; [
> cron_userdomain_transition ]
>
> Did I overlooked something?

What output do you get from:
$ compute_av staff_u:staff_r:cronjob_t:s0 
staff_u:object_r:user_cron_spool_t:s0 file

Likewise, for the attached trivial program, what output do you get from:
$ ./check_access staff_u:staff_r:cronjob_t:s0 
staff_u:object_r:cronjob_t:s0 file entrypoint

[-- Attachment #2: check_access.c --]
[-- Type: text/plain, Size: 498 bytes --]

#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
#include <errno.h>
#include <string.h>
#include <selinux/selinux.h>

int main(int argc, char **argv)
{
	int ret;

	if (argc != 5) {
		fprintf(stderr, "usage:  %s scontext tcontext tclass permission\n",
			argv[0]);
		exit(1);
	}

	ret = selinux_check_access(argv[1], argv[2], argv[3], argv[4], NULL);
	if (ret < 0) {
		fprintf(stderr, "selinux_check_access failed: %s\n", strerror(errno));
		exit(2);
	}

	printf("allowed\n");
	exit(0);
}

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Laurent Bigonville]

Le 23/11/15 17:21, Stephen Smalley a écrit :
> On 11/22/2015 07:53 PM, Laurent Bigonville wrote:
>> Hi,
>>
>> I'm still looking at adding SELinux support in the "at" daemon and I now
>> have the following patch[0].
>>
>> With this patch, at seems to behave like the cron daemon, as explained
>> in the commit log:
>>
>>      - When cron_userdomain_transition is set to off, a process for an
>>        unconfined user will transition to unconfined_cronjob_t. For
>> confined
>>        user, the job is run as cronjob_t.
>>
>>      - When cron_userdomain_transition is set to on, the processes 
>> are run
>>        under the user default context.
>>
>> But every time an AVC denial is generated (with
>> cron_userdomain_transition set to off and the user running as staff_u,
>> in permissive with unmodified refpolicy):
>>
>> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
>> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>>
>> The job runs as (id -Z): staff_u:staff_r:cronjob_t:s0
>>
>> But audit2{allow,why} are saying that this is already allowed in the 
>> policy
>>
>> Setting the cron_userdomain_transition boolean to on, I have the
>> following avc:
>>
>> avc:  denied  { entrypoint } for scontext=staff_u:sysadm_r:sysadm_t:s0
>> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>>
>> The job runs as (id -Z): staff_u:sysadm_r:sysadm_t:s0
>>
>> So as said it seems to work, but I'm not sure why this AVC denial is
>> generated.
>>
>> sesearch shows:
>>
>> $ sesearch -ATSC  -t user_cron_spool_t -c file -p entrypoint
>> Found 6 semantic av rules:
>>     allow files_unconfined_type file_type : file { ioctl read write
>> create getattr setattr lock relabelfrom relabelto append unlink link
>> rename execute swapon quotaon mounton execute_no_trans entrypoint open
>> audit_access } ;
>> DT allow unconfined_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>> DT allow user_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>> EF allow cronjob_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>> DT allow staff_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>> DT allow sysadm_t user_cron_spool_t : file entrypoint ; [
>> cron_userdomain_transition ]
>>
>> Did I overlooked something?
>
> What output do you get from:
> $ compute_av staff_u:staff_r:cronjob_t:s0 
> staff_u:object_r:user_cron_spool_t:s0 file
>
$ /usr/sbin/compute_av staff_u:staff_r:cronjob_t:s0 
staff_u:object_r:user_cron_spool_t:s0 file
allowed= { entrypoint }

> Likewise, for the attached trivial program, what output do you get from:
> $ ./check_access staff_u:staff_r:cronjob_t:s0 
> staff_u:object_r:cronjob_t:s0 file entrypoint
$ ./check_access staff_u:staff_r:cronjob_t:s0 
staff_u:object_r:cronjob_t:s0 file entrypoint
avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0 
tcontext=staff_u:object_r:cronjob_t:s0 tclass=file
allowed
$ ./check_access staff_u:staff_r:cronjob_t:s0 
staff_u:object_r:user_cron_spool_t:s0 file entrypoint
allowed

The above result is what I get with debian unstable and the kernel 4.2

BUT with the kernel 4.3 from experimental (same machine, just updated 
kernel), I get:

$ /usr/sbin/compute_av staff_u:staff_r:cronjob_t:s0 
staff_u:object_r:user_cron_spool_t:s0 file
allowed= null

$ ./check_access staff_u:staff_r:cronjob_t:s0 
staff_u:object_r:cronjob_t:s0 file entrypoint
avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0 
tcontext=staff_u:object_r:cronjob_t:s0 tclass=file
allowed
$ ./check_access staff_u:staff_r:cronjob_t:s0 
staff_u:object_r:user_cron_spool_t:s0 file entrypoint
avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0 
tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
allowed

As you can see the results are different... So this seems to be 
regression at the kernel level.

Cheers,

Laurent Bigonville

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Stephen Smalley]

On 11/23/2015 12:25 PM, Laurent Bigonville wrote:
> Le 23/11/15 17:21, Stephen Smalley a écrit :
>> On 11/22/2015 07:53 PM, Laurent Bigonville wrote:
>>> Hi,
>>>
>>> I'm still looking at adding SELinux support in the "at" daemon and I now
>>> have the following patch[0].
>>>
>>> With this patch, at seems to behave like the cron daemon, as explained
>>> in the commit log:
>>>
>>>      - When cron_userdomain_transition is set to off, a process for an
>>>        unconfined user will transition to unconfined_cronjob_t. For
>>> confined
>>>        user, the job is run as cronjob_t.
>>>
>>>      - When cron_userdomain_transition is set to on, the processes
>>> are run
>>>        under the user default context.
>>>
>>> But every time an AVC denial is generated (with
>>> cron_userdomain_transition set to off and the user running as staff_u,
>>> in permissive with unmodified refpolicy):
>>>
>>> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
>>> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>>>
>>> The job runs as (id -Z): staff_u:staff_r:cronjob_t:s0
>>>
>>> But audit2{allow,why} are saying that this is already allowed in the
>>> policy
>>>
>>> Setting the cron_userdomain_transition boolean to on, I have the
>>> following avc:
>>>
>>> avc:  denied  { entrypoint } for scontext=staff_u:sysadm_r:sysadm_t:s0
>>> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
>>>
>>> The job runs as (id -Z): staff_u:sysadm_r:sysadm_t:s0
>>>
>>> So as said it seems to work, but I'm not sure why this AVC denial is
>>> generated.
>>>
>>> sesearch shows:
>>>
>>> $ sesearch -ATSC  -t user_cron_spool_t -c file -p entrypoint
>>> Found 6 semantic av rules:
>>>     allow files_unconfined_type file_type : file { ioctl read write
>>> create getattr setattr lock relabelfrom relabelto append unlink link
>>> rename execute swapon quotaon mounton execute_no_trans entrypoint open
>>> audit_access } ;
>>> DT allow unconfined_t user_cron_spool_t : file entrypoint ; [
>>> cron_userdomain_transition ]
>>> DT allow user_t user_cron_spool_t : file entrypoint ; [
>>> cron_userdomain_transition ]
>>> EF allow cronjob_t user_cron_spool_t : file entrypoint ; [
>>> cron_userdomain_transition ]
>>> DT allow staff_t user_cron_spool_t : file entrypoint ; [
>>> cron_userdomain_transition ]
>>> DT allow sysadm_t user_cron_spool_t : file entrypoint ; [
>>> cron_userdomain_transition ]
>>>
>>> Did I overlooked something?
>>
>> What output do you get from:
>> $ compute_av staff_u:staff_r:cronjob_t:s0
>> staff_u:object_r:user_cron_spool_t:s0 file
>>
> $ /usr/sbin/compute_av staff_u:staff_r:cronjob_t:s0
> staff_u:object_r:user_cron_spool_t:s0 file
> allowed= { entrypoint }
>
>> Likewise, for the attached trivial program, what output do you get from:
>> $ ./check_access staff_u:staff_r:cronjob_t:s0
>> staff_u:object_r:cronjob_t:s0 file entrypoint
> $ ./check_access staff_u:staff_r:cronjob_t:s0
> staff_u:object_r:cronjob_t:s0 file entrypoint
> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
> tcontext=staff_u:object_r:cronjob_t:s0 tclass=file
> allowed
> $ ./check_access staff_u:staff_r:cronjob_t:s0
> staff_u:object_r:user_cron_spool_t:s0 file entrypoint
> allowed
>
> The above result is what I get with debian unstable and the kernel 4.2
>
> BUT with the kernel 4.3 from experimental (same machine, just updated
> kernel), I get:
>
> $ /usr/sbin/compute_av staff_u:staff_r:cronjob_t:s0
> staff_u:object_r:user_cron_spool_t:s0 file
> allowed= null
>
> $ ./check_access staff_u:staff_r:cronjob_t:s0
> staff_u:object_r:cronjob_t:s0 file entrypoint
> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
> tcontext=staff_u:object_r:cronjob_t:s0 tclass=file
> allowed
> $ ./check_access staff_u:staff_r:cronjob_t:s0
> staff_u:object_r:user_cron_spool_t:s0 file entrypoint
> avc:  denied  { entrypoint } for scontext=staff_u:staff_r:cronjob_t:s0
> tcontext=staff_u:object_r:user_cron_spool_t:s0 tclass=file
> allowed
>
> As you can see the results are different... So this seems to be
> regression at the kernel level.

Well, that depends - are you loading the same policy into both?  What do 
you have in /etc/selinux/targeted/policy?  A policy.29 and a policy.30? 
  What does your libsepol/checkpolicy support?

Or, alternatively, are you toggling cron_userdomain_transition and 
thereby changing the result?

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Laurent Bigonville]

Le 23/11/15 19:44, Stephen Smalley a écrit :
> On 11/23/2015 12:25 PM, Laurent Bigonville wrote:
>> As you can see the results are different... So this seems to be
>> regression at the kernel level.
>
> Well, that depends - are you loading the same policy into both? What
> do you have in /etc/selinux/targeted/policy?  A policy.29 and a
> policy.30?  What does your libsepol/checkpolicy support?
>
> Or, alternatively, are you toggling cron_userdomain_transition and
> thereby changing the result?

It's the same policy loaded, for both kernel version (I'm just choosing 
an other kernel in grub), I only have one policy file.

# ls /etc/selinux/refpolicy/policy/
policy.29

I've the latest released userspace (2.4), policydb.h shows max version 
being 29.

The policyvers utility shows: 30 with 4.3 and 29 with 4.2

Re: (Userspace) AVC denial generated even if allowed by the policy?

[Stephen Smalley]

On 11/23/2015 02:06 PM, Laurent Bigonville wrote:
> Le 23/11/15 19:44, Stephen Smalley a écrit :
>> On 11/23/2015 12:25 PM, Laurent Bigonville wrote:
>>> As you can see the results are different... So this seems to be
>>> regression at the kernel level.
>>
>> Well, that depends - are you loading the same policy into both? What
>> do you have in /etc/selinux/targeted/policy?  A policy.29 and a
>> policy.30?  What does your libsepol/checkpolicy support?
>>
>> Or, alternatively, are you toggling cron_userdomain_transition and
>> thereby changing the result?
>
> It's the same policy loaded, for both kernel version (I'm just choosing
> an other kernel in grub), I only have one policy file.
>
> # ls /etc/selinux/refpolicy/policy/
> policy.29
>
> I've the latest released userspace (2.4), policydb.h shows max version
> being 29.
>
> The policyvers utility shows: 30 with 4.3 and 29 with 4.2

You are correct - this is a kernel bug.  Hidden on Fedora because these 
rules are unconditional there...