SELinux-Refpolicy Archive on lore.kernel.org
 help / Atom feed
* [PATCH] New interface to dontaudit access to cert_t
@ 2019-02-12 13:05 Sugar, David
  2019-02-13 23:42 ` Chris PeBenito
  0 siblings, 1 reply; 6+ messages in thread
From: Sugar, David @ 2019-02-12 13:05 UTC (permalink / raw)
  To: selinux-refpolicy

I'm seeing a bunch of denials for various processes (some refpolicy
domains, some my own application domains) attempting to access
/etc/pki.  They seem to be working OK even with the denial.  Adding
interface to dontaudit this stuff and calling the interface.

type=AVC msg=audit(1549932300.668:266): avc:  denied  { search } for pid=7077 comm="X" name="pki" dev="dm-1" ino=138 scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
type=AVC msg=audit(1549932306.553:430): avc:  denied  { search } for pid=7345 comm="clamd" name="pki" dev="dm-1" ino=138 scontext=system_u:system_r:clamd_t:s0:c1 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0

Signed-off-by: Dave Sugar <dsugar@tresys.com>
---
 policy/modules/services/clamav.te  |  1 +
 policy/modules/services/xserver.te |  1 +
 policy/modules/system/miscfiles.if | 20 ++++++++++++++++++++
 3 files changed, 22 insertions(+)

diff --git a/policy/modules/services/clamav.te b/policy/modules/services/clamav.te
index 622453e3..ad19cc7b 100644
--- a/policy/modules/services/clamav.te
+++ b/policy/modules/services/clamav.te
@@ -147,6 +147,7 @@ auth_use_nsswitch(clamd_t)
 
 logging_send_syslog_msg(clamd_t)
 
+miscfiles_dontaudit_search_generic_certs(clamd_t)
 miscfiles_read_localization(clamd_t)
 
 tunable_policy(`clamd_use_jit',`
diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
index a2b08a89..da1c0c7d 100644
--- a/policy/modules/services/xserver.te
+++ b/policy/modules/services/xserver.te
@@ -804,6 +804,7 @@ locallogin_use_fds(xserver_t)
 logging_send_syslog_msg(xserver_t)
 logging_send_audit_msgs(xserver_t)
 
+miscfiles_dontaudit_search_generic_certs(xserver_t)
 miscfiles_read_localization(xserver_t)
 miscfiles_read_fonts(xserver_t)
 
diff --git a/policy/modules/system/miscfiles.if b/policy/modules/system/miscfiles.if
index 93c1f9c1..cecdb406 100644
--- a/policy/modules/system/miscfiles.if
+++ b/policy/modules/system/miscfiles.if
@@ -131,6 +131,26 @@ interface(`miscfiles_read_generic_certs',`
 	read_lnk_files_pattern($1, cert_t, cert_t)
 ')
 
+########################################
+## <summary>
+##	Do not audit attempts to search
+##	on a generic certs directory.
+## </summary>
+## <param name="domain">
+##	<summary>
+##	Domain to not audit.
+##	</summary>
+## </param>
+## <rolecap/>
+#
+interface(`miscfiles_dontaudit_search_generic_certs',`
+	gen_require(`
+		type cert_t;
+	')
+
+	dontaudit $1 cert_t:dir search;
+')
+
 ########################################
 ## <summary>
 ##	Manage generic SSL/TLS certificates.
-- 
2.20.1


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] New interface to dontaudit access to cert_t
  2019-02-12 13:05 [PATCH] New interface to dontaudit access to cert_t Sugar, David
@ 2019-02-13 23:42 ` Chris PeBenito
  2019-02-14 13:56   ` Sugar, David
  0 siblings, 1 reply; 6+ messages in thread
From: Chris PeBenito @ 2019-02-13 23:42 UTC (permalink / raw)
  To: Sugar, David, selinux-refpolicy

On 2/12/19 8:05 AM, Sugar, David wrote:
> I'm seeing a bunch of denials for various processes (some refpolicy
> domains, some my own application domains) attempting to access
> /etc/pki.  They seem to be working OK even with the denial.  Adding
> interface to dontaudit this stuff and calling the interface.
> 
> type=AVC msg=audit(1549932300.668:266): avc:  denied  { search } for pid=7077 comm="X" name="pki" dev="dm-1" ino=138 scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
> type=AVC msg=audit(1549932306.553:430): avc:  denied  { search } for pid=7345 comm="clamd" name="pki" dev="dm-1" ino=138 scontext=system_u:system_r:clamd_t:s0:c1 tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0

My guess is there is some common library between them (maybe glibc) 
which is triggering this.  It seems like this might potentially cover up 
legitimate access.  It's just hard to tell by just dir searches.


> Signed-off-by: Dave Sugar <dsugar@tresys.com>
> ---
>   policy/modules/services/clamav.te  |  1 +
>   policy/modules/services/xserver.te |  1 +
>   policy/modules/system/miscfiles.if | 20 ++++++++++++++++++++
>   3 files changed, 22 insertions(+)
> 
> diff --git a/policy/modules/services/clamav.te b/policy/modules/services/clamav.te
> index 622453e3..ad19cc7b 100644
> --- a/policy/modules/services/clamav.te
> +++ b/policy/modules/services/clamav.te
> @@ -147,6 +147,7 @@ auth_use_nsswitch(clamd_t)
>   
>   logging_send_syslog_msg(clamd_t)
>   
> +miscfiles_dontaudit_search_generic_certs(clamd_t)
>   miscfiles_read_localization(clamd_t)
>   
>   tunable_policy(`clamd_use_jit',`
> diff --git a/policy/modules/services/xserver.te b/policy/modules/services/xserver.te
> index a2b08a89..da1c0c7d 100644
> --- a/policy/modules/services/xserver.te
> +++ b/policy/modules/services/xserver.te
> @@ -804,6 +804,7 @@ locallogin_use_fds(xserver_t)
>   logging_send_syslog_msg(xserver_t)
>   logging_send_audit_msgs(xserver_t)
>   
> +miscfiles_dontaudit_search_generic_certs(xserver_t)
>   miscfiles_read_localization(xserver_t)
>   miscfiles_read_fonts(xserver_t)
>   
> diff --git a/policy/modules/system/miscfiles.if b/policy/modules/system/miscfiles.if
> index 93c1f9c1..cecdb406 100644
> --- a/policy/modules/system/miscfiles.if
> +++ b/policy/modules/system/miscfiles.if
> @@ -131,6 +131,26 @@ interface(`miscfiles_read_generic_certs',`
>   	read_lnk_files_pattern($1, cert_t, cert_t)
>   ')
>   
> +########################################
> +## <summary>
> +##	Do not audit attempts to search
> +##	on a generic certs directory.
> +## </summary>
> +## <param name="domain">
> +##	<summary>
> +##	Domain to not audit.
> +##	</summary>
> +## </param>
> +## <rolecap/>
> +#
> +interface(`miscfiles_dontaudit_search_generic_certs',`
> +	gen_require(`
> +		type cert_t;
> +	')
> +
> +	dontaudit $1 cert_t:dir search;
> +')
> +
>   ########################################
>   ## <summary>
>   ##	Manage generic SSL/TLS certificates.
> 


-- 
Chris PeBenito

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] New interface to dontaudit access to cert_t
  2019-02-13 23:42 ` Chris PeBenito
@ 2019-02-14 13:56   ` Sugar, David
  2019-02-16 19:40     ` Chris PeBenito
  0 siblings, 1 reply; 6+ messages in thread
From: Sugar, David @ 2019-02-14 13:56 UTC (permalink / raw)
  To: selinux-refpolicy



On 2/13/19 6:42 PM, Chris PeBenito wrote:
> On 2/12/19 8:05 AM, Sugar, David wrote:
>> I'm seeing a bunch of denials for various processes (some refpolicy
>> domains, some my own application domains) attempting to access
>> /etc/pki.  They seem to be working OK even with the denial.  Adding
>> interface to dontaudit this stuff and calling the interface.
>>
>> type=AVC msg=audit(1549932300.668:266): avc:  denied  { search } for 
>> pid=7077 comm="X" name="pki" dev="dm-1" ino=138 
>> scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023 
>> tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
>> type=AVC msg=audit(1549932306.553:430): avc:  denied  { search } for 
>> pid=7345 comm="clamd" name="pki" dev="dm-1" ino=138 
>> scontext=system_u:system_r:clamd_t:s0:c1 
>> tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
> 
> My guess is there is some common library between them (maybe glibc) 
> which is triggering this.  It seems like this might potentially cover up 
> legitimate access.  It's just hard to tell by just dir searches.
> 

Digging into this I have found a few things, and please note that I am 
not seeing this denial in permissive.

Looking at strace for clamd I see an attempt to open the (non-existent) 
file /etc/pki/tls/legacy-settings.  I think this would explain the 
denial on dir search.

If I create that file (even empty) labeled cert_t I see denials (in 
permissive) for clamd_t cert_t:file { getattr open read }.

audit2allow suggests the boolean 'authlogin_nsswitch_use_ldap' should 
resolve the issue (for clamd_t).  This makes sense as clamd uses the 
interface auth_use_nsswitch(clamd_t).

So, assuming that I don't want to enable 'authlogin_nsswitch_use_ldap' 
is there a way to quiet this denial?

Maybe this has to do with dropping from root to the clamscan user.

Would it be acceptable to apply the patch to miscfiles.if for use in my 
application domains but not accept the patches for clamav and xserver?

> 
>> Signed-off-by: Dave Sugar <dsugar@tresys.com>
>> ---
>>   policy/modules/services/clamav.te  |  1 +
>>   policy/modules/services/xserver.te |  1 +
>>   policy/modules/system/miscfiles.if | 20 ++++++++++++++++++++
>>   3 files changed, 22 insertions(+)
>>
>> diff --git a/policy/modules/services/clamav.te 
>> b/policy/modules/services/clamav.te
>> index 622453e3..ad19cc7b 100644
>> --- a/policy/modules/services/clamav.te
>> +++ b/policy/modules/services/clamav.te
>> @@ -147,6 +147,7 @@ auth_use_nsswitch(clamd_t)
>>   logging_send_syslog_msg(clamd_t)
>> +miscfiles_dontaudit_search_generic_certs(clamd_t)
>>   miscfiles_read_localization(clamd_t)
>>   tunable_policy(`clamd_use_jit',`
>> diff --git a/policy/modules/services/xserver.te 
>> b/policy/modules/services/xserver.te
>> index a2b08a89..da1c0c7d 100644
>> --- a/policy/modules/services/xserver.te
>> +++ b/policy/modules/services/xserver.te
>> @@ -804,6 +804,7 @@ locallogin_use_fds(xserver_t)
>>   logging_send_syslog_msg(xserver_t)
>>   logging_send_audit_msgs(xserver_t)
>> +miscfiles_dontaudit_search_generic_certs(xserver_t)
>>   miscfiles_read_localization(xserver_t)
>>   miscfiles_read_fonts(xserver_t)
>> diff --git a/policy/modules/system/miscfiles.if 
>> b/policy/modules/system/miscfiles.if
>> index 93c1f9c1..cecdb406 100644
>> --- a/policy/modules/system/miscfiles.if
>> +++ b/policy/modules/system/miscfiles.if
>> @@ -131,6 +131,26 @@ interface(`miscfiles_read_generic_certs',`
>>       read_lnk_files_pattern($1, cert_t, cert_t)
>>   ')
>> +########################################
>> +## <summary>
>> +##    Do not audit attempts to search
>> +##    on a generic certs directory.
>> +## </summary>
>> +## <param name="domain">
>> +##    <summary>
>> +##    Domain to not audit.
>> +##    </summary>
>> +## </param>
>> +## <rolecap/>
>> +#
>> +interface(`miscfiles_dontaudit_search_generic_certs',`
>> +    gen_require(`
>> +        type cert_t;
>> +    ')
>> +
>> +    dontaudit $1 cert_t:dir search;
>> +')
>> +
>>   ########################################
>>   ## <summary>
>>   ##    Manage generic SSL/TLS certificates.
>>
> 
> 

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] New interface to dontaudit access to cert_t
  2019-02-14 13:56   ` Sugar, David
@ 2019-02-16 19:40     ` Chris PeBenito
  2019-02-17 16:34       ` Sugar, David
  0 siblings, 1 reply; 6+ messages in thread
From: Chris PeBenito @ 2019-02-16 19:40 UTC (permalink / raw)
  To: Sugar, David, selinux-refpolicy

On 2/14/19 8:56 AM, Sugar, David wrote:
> 
> 
> On 2/13/19 6:42 PM, Chris PeBenito wrote:
>> On 2/12/19 8:05 AM, Sugar, David wrote:
>>> I'm seeing a bunch of denials for various processes (some refpolicy
>>> domains, some my own application domains) attempting to access
>>> /etc/pki.  They seem to be working OK even with the denial.  Adding
>>> interface to dontaudit this stuff and calling the interface.
>>>
>>> type=AVC msg=audit(1549932300.668:266): avc:  denied  { search } for
>>> pid=7077 comm="X" name="pki" dev="dm-1" ino=138
>>> scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
>>> tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
>>> type=AVC msg=audit(1549932306.553:430): avc:  denied  { search } for
>>> pid=7345 comm="clamd" name="pki" dev="dm-1" ino=138
>>> scontext=system_u:system_r:clamd_t:s0:c1
>>> tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
>>
>> My guess is there is some common library between them (maybe glibc)
>> which is triggering this.  It seems like this might potentially cover up
>> legitimate access.  It's just hard to tell by just dir searches.
>>
> 
> Digging into this I have found a few things, and please note that I am
> not seeing this denial in permissive.
> 
> Looking at strace for clamd I see an attempt to open the (non-existent)
> file /etc/pki/tls/legacy-settings.  I think this would explain the
> denial on dir search.
> 
> If I create that file (even empty) labeled cert_t I see denials (in
> permissive) for clamd_t cert_t:file { getattr open read }.
> 
> audit2allow suggests the boolean 'authlogin_nsswitch_use_ldap' should
> resolve the issue (for clamd_t).  This makes sense as clamd uses the
> interface auth_use_nsswitch(clamd_t).
> 
> So, assuming that I don't want to enable 'authlogin_nsswitch_use_ldap'
> is there a way to quiet this denial?

The dontaudit could go in the else block for that tunable.

-- 
Chris PeBenito

^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] New interface to dontaudit access to cert_t
  2019-02-16 19:40     ` Chris PeBenito
@ 2019-02-17 16:34       ` Sugar, David
  2019-02-20  3:33         ` Chris PeBenito
  0 siblings, 1 reply; 6+ messages in thread
From: Sugar, David @ 2019-02-17 16:34 UTC (permalink / raw)
  To: Chris PeBenito, selinux-refpolicy



On 2/16/19 2:40 PM, Chris PeBenito wrote:
> On 2/14/19 8:56 AM, Sugar, David wrote:
>>
>>
>> On 2/13/19 6:42 PM, Chris PeBenito wrote:
>>> On 2/12/19 8:05 AM, Sugar, David wrote:
>>>> I'm seeing a bunch of denials for various processes (some refpolicy
>>>> domains, some my own application domains) attempting to access
>>>> /etc/pki.  They seem to be working OK even with the denial.  Adding
>>>> interface to dontaudit this stuff and calling the interface.
>>>>
>>>> type=AVC msg=audit(1549932300.668:266): avc:  denied  { search } for
>>>> pid=7077 comm="X" name="pki" dev="dm-1" ino=138
>>>> scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
>>>> tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
>>>> type=AVC msg=audit(1549932306.553:430): avc:  denied  { search } for
>>>> pid=7345 comm="clamd" name="pki" dev="dm-1" ino=138
>>>> scontext=system_u:system_r:clamd_t:s0:c1
>>>> tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
>>>
>>> My guess is there is some common library between them (maybe glibc)
>>> which is triggering this.  It seems like this might potentially cover up
>>> legitimate access.  It's just hard to tell by just dir searches.
>>>
>>
>> Digging into this I have found a few things, and please note that I am
>> not seeing this denial in permissive.
>>
>> Looking at strace for clamd I see an attempt to open the (non-existent)
>> file /etc/pki/tls/legacy-settings.  I think this would explain the
>> denial on dir search.
>>
>> If I create that file (even empty) labeled cert_t I see denials (in
>> permissive) for clamd_t cert_t:file { getattr open read }.
>>
>> audit2allow suggests the boolean 'authlogin_nsswitch_use_ldap' should
>> resolve the issue (for clamd_t).  This makes sense as clamd uses the
>> interface auth_use_nsswitch(clamd_t).
>>
>> So, assuming that I don't want to enable 'authlogin_nsswitch_use_ldap'
>> is there a way to quiet this denial?
> 
> The dontaudit could go in the else block for that tunable.
> 
That works for me.  In this case though, should I leave the interface as 
proposed before or would it be more preferable to don't audit access to 
cert_t files along with directories?

So change the interface to miscfiles_dontaudit_read_generic_certs and 
include dontaudit rules for list_dir_perms, read_file_perms, 
read_lnk_file_perms.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: [PATCH] New interface to dontaudit access to cert_t
  2019-02-17 16:34       ` Sugar, David
@ 2019-02-20  3:33         ` Chris PeBenito
  0 siblings, 0 replies; 6+ messages in thread
From: Chris PeBenito @ 2019-02-20  3:33 UTC (permalink / raw)
  To: Sugar, David, selinux-refpolicy

On Sun, 2019-02-17 at 16:34 +0000, Sugar, David wrote:
> 
> On 2/16/19 2:40 PM, Chris PeBenito wrote:
> > On 2/14/19 8:56 AM, Sugar, David wrote:
> > > 
> > > On 2/13/19 6:42 PM, Chris PeBenito wrote:
> > > > On 2/12/19 8:05 AM, Sugar, David wrote:
> > > > > I'm seeing a bunch of denials for various processes (some
> > > > > refpolicy
> > > > > domains, some my own application domains) attempting to
> > > > > access
> > > > > /etc/pki.  They seem to be working OK even with the denial. 
> > > > > Adding
> > > > > interface to dontaudit this stuff and calling the interface.
> > > > > 
> > > > > type=AVC msg=audit(1549932300.668:266): avc:  denied  {
> > > > > search } for
> > > > > pid=7077 comm="X" name="pki" dev="dm-1" ino=138
> > > > > scontext=system_u:system_r:xserver_t:s0-s0:c0.c1023
> > > > > tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
> > > > > type=AVC msg=audit(1549932306.553:430): avc:  denied  {
> > > > > search } for
> > > > > pid=7345 comm="clamd" name="pki" dev="dm-1" ino=138
> > > > > scontext=system_u:system_r:clamd_t:s0:c1
> > > > > tcontext=system_u:object_r:cert_t:s0 tclass=dir permissive=0
> > > > 
> > > > My guess is there is some common library between them (maybe
> > > > glibc)
> > > > which is triggering this.  It seems like this might potentially
> > > > cover up
> > > > legitimate access.  It's just hard to tell by just dir
> > > > searches.
> > > > 
> > > 
> > > Digging into this I have found a few things, and please note that
> > > I am
> > > not seeing this denial in permissive.
> > > 
> > > Looking at strace for clamd I see an attempt to open the (non-
> > > existent)
> > > file /etc/pki/tls/legacy-settings.  I think this would explain
> > > the
> > > denial on dir search.
> > > 
> > > If I create that file (even empty) labeled cert_t I see denials
> > > (in
> > > permissive) for clamd_t cert_t:file { getattr open read }.
> > > 
> > > audit2allow suggests the boolean 'authlogin_nsswitch_use_ldap'
> > > should
> > > resolve the issue (for clamd_t).  This makes sense as clamd uses
> > > the
> > > interface auth_use_nsswitch(clamd_t).
> > > 
> > > So, assuming that I don't want to enable
> > > 'authlogin_nsswitch_use_ldap'
> > > is there a way to quiet this denial?
> > 
> > The dontaudit could go in the else block for that tunable.
> > 
> That works for me.  In this case though, should I leave the interface
> as 
> proposed before or would it be more preferable to don't audit access
> to 
> cert_t files along with directories?

The latter is preferable.

-- 
Chris PeBenito



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, back to index

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-12 13:05 [PATCH] New interface to dontaudit access to cert_t Sugar, David
2019-02-13 23:42 ` Chris PeBenito
2019-02-14 13:56   ` Sugar, David
2019-02-16 19:40     ` Chris PeBenito
2019-02-17 16:34       ` Sugar, David
2019-02-20  3:33         ` Chris PeBenito

SELinux-Refpolicy Archive on lore.kernel.org

Archives are clonable:
	git clone --mirror https://lore.kernel.org/selinux-refpolicy/0 selinux-refpolicy/git/0.git

	# If you have public-inbox 1.1+ installed, you may
	# initialize and index your mirror using the following commands:
	public-inbox-init -V2 selinux-refpolicy selinux-refpolicy/ https://lore.kernel.org/selinux-refpolicy \
		selinux-refpolicy@vger.kernel.org selinux-refpolicy@archiver.kernel.org
	public-inbox-index selinux-refpolicy


Newsgroup available over NNTP:
	nntp://nntp.lore.kernel.org/org.kernel.vger.selinux-refpolicy


AGPL code for this site: git clone https://public-inbox.org/ public-inbox