[PATCH 0/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[PATCH 0/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[jeffxu]

From: Jeff Xu <jeffxu@chromium.org>

This patch was originally developed by Luis Hector Chavez
<lhchavez@chromium.org>

For systems that use SECURITY_SELINUX_DEVELOP=y and allow permissive
domains. The audit log from permissive domains can be excessive in
practice, and this patch is useful to avoid the log spam.

Luis Hector Chavez (1):
  Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

 security/selinux/Kconfig | 10 ++++++++++
 security/selinux/avc.c   |  9 +++++++++
 2 files changed, 19 insertions(+)

--
2.37.3.968.ga6b4b080e4-goog

[PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[jeffxu]

From: Jeff Xu <jeffxu@chromium.org>

When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
mode, it is useful to disable logging from permissive domain, so audit
log does not get spamed.

Signed-off-by: Jeff Xu <jeffxu@chromium.org>
Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
Tested-by: Jeff Xu<jeffxu@chromium.org>
---
 security/selinux/Kconfig | 10 ++++++++++
 security/selinux/avc.c   |  9 +++++++++
 2 files changed, 19 insertions(+)

diff --git a/security/selinux/Kconfig b/security/selinux/Kconfig
index 9e921fc72538..99b8b88abc3d 100644
--- a/security/selinux/Kconfig
+++ b/security/selinux/Kconfig
@@ -61,6 +61,16 @@ config SECURITY_SELINUX_DEVELOP
 	  permissive mode (if permitted by the policy) via
 	  /sys/fs/selinux/enforce.
 
+config SECURITY_SELINUX_PERMISSIVE_DONTAUDIT
+	bool "NSA SELinux don't audit permissive"
+	depends on SECURITY_SELINUX
+	default n
+	help
+	  This prevents logging when permissive=1.  If unsure, say N.  With
+	  this option enabled, any avc logs that would occur on a permissive
+	  domain won't be logged.  This can prevent a significant amount of
+	  logspam.
+
 config SECURITY_SELINUX_AVC_STATS
 	bool "NSA SELinux AVC Statistics"
 	depends on SECURITY_SELINUX
diff --git a/security/selinux/avc.c b/security/selinux/avc.c
index 9a43af0ebd7d..2f0a49d7c714 100644
--- a/security/selinux/avc.c
+++ b/security/selinux/avc.c
@@ -777,6 +777,15 @@ noinline int slow_avc_audit(struct selinux_state *state,
 	if (WARN_ON(!tclass || tclass >= ARRAY_SIZE(secclass_map)))
 		return -EINVAL;
 
+	/*
+	 * Avoid logging permissive=1 messages for
+	 * SECURITY_SELINUX_PERMISSIVE_DONTAUDIT.
+	 */
+	if (IS_ENABLED(CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT) && denied
+	    && !result) {
+		return 0;
+	}
+
 	if (!a) {
 		a = &stack_data;
 		a->type = LSM_AUDIT_DATA_NONE;
-- 
2.37.3.968.ga6b4b080e4-goog

Re: [PATCH 0/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Casey Schaufler]

On 9/21/2022 11:54 AM, jeffxu@chromium.org wrote:
> From: Jeff Xu <jeffxu@chromium.org>
>
> This patch was originally developed by Luis Hector Chavez
> <lhchavez@chromium.org>
>
> For systems that use SECURITY_SELINUX_DEVELOP=y and allow permissive
> domains. The audit log from permissive domains can be excessive in
> practice, and this patch is useful to avoid the log spam.

Doesn't this defeat the purpose of permissive mode? If you aren't
logging the events that would have failed how can you learn what
policy you should have? 

>
> Luis Hector Chavez (1):
>   Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT
>
>  security/selinux/Kconfig | 10 ++++++++++
>  security/selinux/avc.c   |  9 +++++++++
>  2 files changed, 19 insertions(+)
>
> --
> 2.37.3.968.ga6b4b080e4-goog
>

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Paul Moore]

On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
>
> From: Jeff Xu <jeffxu@chromium.org>
>
> When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
> mode, it is useful to disable logging from permissive domain, so audit
> log does not get spamed.
>
> Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
> Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
> Tested-by: Jeff Xu<jeffxu@chromium.org>
> ---
>  security/selinux/Kconfig | 10 ++++++++++
>  security/selinux/avc.c   |  9 +++++++++
>  2 files changed, 19 insertions(+)

I'm sorry, but I can't accept this into the upstream kernel.
Permissive mode, both per-domain and system-wide, is not intended to
be a long term solution.  Permissive mode should really only be used
as a development tool or emergency "hotfix" with the proper solution
being either an adjustment of the existing policy (SELinux policy
booleans, labeling changes, etc.) or the development of a new policy
module which better fits your use case.

-- 
paul-moore.com

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Jeff Xu]

On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
> >
> > From: Jeff Xu <jeffxu@chromium.org>
> >
> > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
> > mode, it is useful to disable logging from permissive domain, so audit
> > log does not get spamed.
> >
> > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
> > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
> > Tested-by: Jeff Xu<jeffxu@chromium.org>
> > ---
> >  security/selinux/Kconfig | 10 ++++++++++
> >  security/selinux/avc.c   |  9 +++++++++
> >  2 files changed, 19 insertions(+)
>
> I'm sorry, but I can't accept this into the upstream kernel.
> Permissive mode, both per-domain and system-wide, is not intended to
> be a long term solution.  Permissive mode should really only be used
> as a development tool or emergency "hotfix" with the proper solution
> being either an adjustment of the existing policy (SELinux policy
> booleans, labeling changes, etc.) or the development of a new policy
> module which better fits your use case.
>

Thanks for the response.
For a system that wants to control a few daemons, is there a
recommended pattern from selinux ?
I read this blog about unconfined domain (unconfined_t), maybe this is one way ?
https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes

I have two questions on unconfined domain:
1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ?
2> will unconfined_t domain log also as permissive domain ?

Thanks
Jeff

> --
> paul-moore.com

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Paul Moore]

On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote:
> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
> > >
> > > From: Jeff Xu <jeffxu@chromium.org>
> > >
> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
> > > mode, it is useful to disable logging from permissive domain, so audit
> > > log does not get spamed.
> > >
> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
> > > Tested-by: Jeff Xu<jeffxu@chromium.org>
> > > ---
> > >  security/selinux/Kconfig | 10 ++++++++++
> > >  security/selinux/avc.c   |  9 +++++++++
> > >  2 files changed, 19 insertions(+)
> >
> > I'm sorry, but I can't accept this into the upstream kernel.
> > Permissive mode, both per-domain and system-wide, is not intended to
> > be a long term solution.  Permissive mode should really only be used
> > as a development tool or emergency "hotfix" with the proper solution
> > being either an adjustment of the existing policy (SELinux policy
> > booleans, labeling changes, etc.) or the development of a new policy
> > module which better fits your use case.
>
> Thanks for the response.
> For a system that wants to control a few daemons, is there a
> recommended pattern from selinux ?

Guidance on how to write a SELinux policy for an application is a bit
beyond what I have time for in this email, but others on this mailing
list might be able to help.  There has definitely been a lot written
on the subject, both available online and offline.  My suggestion
would be to start "small" with a single SELinux domain for the
application and a single type for any configuration, data, or log
files it might need; get this initial domain working properly and then
you can add increasing levels of access control granularity until
you've met your security requirements.  If you've never done this
before, go slow, the start might be challenging as you get used to the
tools, but you can do it :)

> I read this blog about unconfined domain (unconfined_t), maybe this is one way ?
> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes

It is important to remember that an unconfined domain is, as the name
would imply, effectively unconfined by SELinux.  Perhaps this is what
you want, but generally speaking if you are running SELinux it is
because you have a need or desire for additional access controls
beyond the legacy Linux discretionary access controls.

> I have two questions on unconfined domain:
> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ?

Yes.  The SECURITY_SELINUX_DEVELOP kernel build configuration only
enables the admin to boot the kernel initially in permissive mode
and/or determine the SELinux mode using the "enforcing=X" kernel
command line option and a sysfs/securityfs tunable under
/sys/fs/selinux/enforce.  The unconfined_t domain is defined purely in
the SELinux policy and not the kernel; you could write a SELinux
policy without it you wanted, or you could grant unconfined_t-like
permissions to multiple different domains in your policy.  It's been a
while since I played with it, but I believe the SELinux reference
policy (refpol) provides a macro interface to define an arbitrary
domain with unconfined_t-like permissions.

> 2> will unconfined_t domain log also as permissive domain ?

The intent of the unconfined_t domain is that there would be no access
denials due to SELinux and thus no AVC audit records related to the
unconfined_t domain.  It is not permissive in the sense of the SELinux
"mode" (enforcing/permissive/disabled), but it is permissive in the
sense that it is given a large number of permissions.

-- 
paul-moore.com

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Dominick Grift]

Paul Moore <paul@paul-moore.com> writes:

> On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote:
>> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
>> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
>> > >
>> > > From: Jeff Xu <jeffxu@chromium.org>
>> > >
>> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
>> > > mode, it is useful to disable logging from permissive domain, so audit
>> > > log does not get spamed.
>> > >
>> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
>> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
>> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
>> > > Tested-by: Jeff Xu<jeffxu@chromium.org>
>> > > ---
>> > >  security/selinux/Kconfig | 10 ++++++++++
>> > >  security/selinux/avc.c   |  9 +++++++++
>> > >  2 files changed, 19 insertions(+)
>> >
>> > I'm sorry, but I can't accept this into the upstream kernel.
>> > Permissive mode, both per-domain and system-wide, is not intended to
>> > be a long term solution.  Permissive mode should really only be used
>> > as a development tool or emergency "hotfix" with the proper solution
>> > being either an adjustment of the existing policy (SELinux policy
>> > booleans, labeling changes, etc.) or the development of a new policy
>> > module which better fits your use case.
>>
>> Thanks for the response.
>> For a system that wants to control a few daemons, is there a
>> recommended pattern from selinux ?

That is effectively a "targeted" policy model. You target a selection of
entities and everything else is "unconfined" (ie not targeteed).

An "unconfined" domain is just a process type that has many allow rules
associated with it making it effectively similar to an "permissive"
domain. The difference is that since "unconfined" domains have full
access there should not be any AVC denials (nothing is blocked by
SELinux because the policy does not target the entity)

The stock policy enforced in Red Hat based distributions is a "targeted"
policy model for example. The unconfined_t domain is one of various
"unconfined" domains (other examples are unconfined_service_t but
effectively any type could be made unconfined by simply allowing all accesses.

>
> Guidance on how to write a SELinux policy for an application is a bit
> beyond what I have time for in this email, but others on this mailing
> list might be able to help.  There has definitely been a lot written
> on the subject, both available online and offline.  My suggestion
> would be to start "small" with a single SELinux domain for the
> application and a single type for any configuration, data, or log
> files it might need; get this initial domain working properly and then
> you can add increasing levels of access control granularity until
> you've met your security requirements.  If you've never done this
> before, go slow, the start might be challenging as you get used to the
> tools, but you can do it :)
>
>> I read this blog about unconfined domain (unconfined_t), maybe this is one way ?
>> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes
>
> It is important to remember that an unconfined domain is, as the name
> would imply, effectively unconfined by SELinux.  Perhaps this is what
> you want, but generally speaking if you are running SELinux it is
> because you have a need or desire for additional access controls
> beyond the legacy Linux discretionary access controls.
>
>> I have two questions on unconfined domain:
>> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ?
>
> Yes.  The SECURITY_SELINUX_DEVELOP kernel build configuration only
> enables the admin to boot the kernel initially in permissive mode
> and/or determine the SELinux mode using the "enforcing=X" kernel
> command line option and a sysfs/securityfs tunable under
> /sys/fs/selinux/enforce.  The unconfined_t domain is defined purely in
> the SELinux policy and not the kernel; you could write a SELinux
> policy without it you wanted, or you could grant unconfined_t-like
> permissions to multiple different domains in your policy.  It's been a
> while since I played with it, but I believe the SELinux reference
> policy (refpol) provides a macro interface to define an arbitrary
> domain with unconfined_t-like permissions.
>
>> 2> will unconfined_t domain log also as permissive domain ?
>
> The intent of the unconfined_t domain is that there would be no access
> denials due to SELinux and thus no AVC audit records related to the
> unconfined_t domain.  It is not permissive in the sense of the SELinux
> "mode" (enforcing/permissive/disabled), but it is permissive in the
> sense that it is given a large number of permissions.

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Jeff Xu]

On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Paul Moore <paul@paul-moore.com> writes:
>
> > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote:
> >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
> >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
> >> > >
> >> > > From: Jeff Xu <jeffxu@chromium.org>
> >> > >
> >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
> >> > > mode, it is useful to disable logging from permissive domain, so audit
> >> > > log does not get spamed.
> >> > >
> >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
> >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
> >> > > Tested-by: Jeff Xu<jeffxu@chromium.org>
> >> > > ---
> >> > >  security/selinux/Kconfig | 10 ++++++++++
> >> > >  security/selinux/avc.c   |  9 +++++++++
> >> > >  2 files changed, 19 insertions(+)
> >> >
> >> > I'm sorry, but I can't accept this into the upstream kernel.
> >> > Permissive mode, both per-domain and system-wide, is not intended to
> >> > be a long term solution.  Permissive mode should really only be used
> >> > as a development tool or emergency "hotfix" with the proper solution
> >> > being either an adjustment of the existing policy (SELinux policy
> >> > booleans, labeling changes, etc.) or the development of a new policy
> >> > module which better fits your use case.
> >>
> >> Thanks for the response.
> >> For a system that wants to control a few daemons, is there a
> >> recommended pattern from selinux ?
>
> That is effectively a "targeted" policy model. You target a selection of
> entities and everything else is "unconfined" (ie not targeteed).
>
> An "unconfined" domain is just a process type that has many allow rules
> associated with it making it effectively similar to an "permissive"
> domain. The difference is that since "unconfined" domains have full
> access there should not be any AVC denials (nothing is blocked by
> SELinux because the policy does not target the entity)
>
> The stock policy enforced in Red Hat based distributions is a "targeted"
> policy model for example. The unconfined_t domain is one of various
> "unconfined" domains (other examples are unconfined_service_t but
> effectively any type could be made unconfined by simply allowing all accesses.
>
> >
> > Guidance on how to write a SELinux policy for an application is a bit
> > beyond what I have time for in this email, but others on this mailing
> > list might be able to help.  There has definitely been a lot written
> > on the subject, both available online and offline.  My suggestion
> > would be to start "small" with a single SELinux domain for the
> > application and a single type for any configuration, data, or log
> > files it might need; get this initial domain working properly and then
> > you can add increasing levels of access control granularity until
> > you've met your security requirements.  If you've never done this
> > before, go slow, the start might be challenging as you get used to the
> > tools, but you can do it :)
> >
> >> I read this blog about unconfined domain (unconfined_t), maybe this is one way ?
> >> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes
> >
> > It is important to remember that an unconfined domain is, as the name
> > would imply, effectively unconfined by SELinux.  Perhaps this is what
> > you want, but generally speaking if you are running SELinux it is
> > because you have a need or desire for additional access controls
> > beyond the legacy Linux discretionary access controls.
> >
> >> I have two questions on unconfined domain:
> >> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ?
> >
> > Yes.  The SECURITY_SELINUX_DEVELOP kernel build configuration only
> > enables the admin to boot the kernel initially in permissive mode
> > and/or determine the SELinux mode using the "enforcing=X" kernel
> > command line option and a sysfs/securityfs tunable under
> > /sys/fs/selinux/enforce.  The unconfined_t domain is defined purely in
> > the SELinux policy and not the kernel; you could write a SELinux
> > policy without it you wanted, or you could grant unconfined_t-like
> > permissions to multiple different domains in your policy.  It's been a
> > while since I played with it, but I believe the SELinux reference
> > policy (refpol) provides a macro interface to define an arbitrary
> > domain with unconfined_t-like permissions.
> >
> >> 2> will unconfined_t domain log also as permissive domain ?
> >
> > The intent of the unconfined_t domain is that there would be no access
> > denials due to SELinux and thus no AVC audit records related to the
> > unconfined_t domain.  It is not permissive in the sense of the SELinux
> > "mode" (enforcing/permissive/disabled), but it is permissive in the
> > sense that it is given a large number of permissions.
>
> --
> gpg --locate-keys dominick.grift@defensec.nl
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift

Thanks for details about the unconfined_t domain, this is one option.

IMHO: between permissive domain + audit log and unconfined_t, there might
be room for letting each permissive domain decide its own audit logging
strategy. The reasons are:

1> For a system that have many daemons, a lot of those are not actively
worked by devs, relying on tests is not sufficient to discover all possible
legitimate accesses  at runtime, dev won't be comfortable to enable enforced
mode without some bake time in production, this is where permissive + audit log
helps.

2> The set back of "permissive + audit log" is that one daemon might generate
too much log in production, set to unconfined_t is one option, but
then dev revert
the progress made so far with permissive mode.

3> For a system that is on continuous delivery pipeline, during the phase of
development of selinux policy, daemon owner might need permissive + audit log
in testing, but permissive - audit log in production. This is where
the per-domain
audit log can help, it would be even nicer if this can be controlled
at runtime,
similar to sysctl.

Best regards,
Jeff

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Paul Moore]

On Mon, Sep 26, 2022 at 2:03 PM Jeff Xu <jeffxu@chromium.org> wrote:
> Thanks for details about the unconfined_t domain, this is one option.
>
> IMHO: between permissive domain + audit log and unconfined_t, there might
> be room for letting each permissive domain decide its own audit logging
> strategy. The reasons are ...

I'm sorry, but I don't want to support a permissive mode that doesn't
generate denial records in the upstream kernel at this point in time.

-- 
paul-moore.com

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Jeff Xu]

On Mon, Sep 26, 2022 at 2:41 PM Paul Moore <paul@paul-moore.com> wrote:
>
> On Mon, Sep 26, 2022 at 2:03 PM Jeff Xu <jeffxu@chromium.org> wrote:
> > Thanks for details about the unconfined_t domain, this is one option.
> >
> > IMHO: between permissive domain + audit log and unconfined_t, there might
> > be room for letting each permissive domain decide its own audit logging
> > strategy. The reasons are ...
>
> I'm sorry, but I don't want to support a permissive mode that doesn't
> generate denial records in the upstream kernel at this point in time.
>
No problem, I understand.

Thanks
Best Regards
Jeff

> --
> paul-moore.com

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Jeff Xu]

On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift
<dominick.grift@defensec.nl> wrote:
>
> Paul Moore <paul@paul-moore.com> writes:
>
> > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote:
> >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
> >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
> >> > >
> >> > > From: Jeff Xu <jeffxu@chromium.org>
> >> > >
> >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
> >> > > mode, it is useful to disable logging from permissive domain, so audit
> >> > > log does not get spamed.
> >> > >
> >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
> >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
> >> > > Tested-by: Jeff Xu<jeffxu@chromium.org>
> >> > > ---
> >> > >  security/selinux/Kconfig | 10 ++++++++++
> >> > >  security/selinux/avc.c   |  9 +++++++++
> >> > >  2 files changed, 19 insertions(+)
> >> >
> >> > I'm sorry, but I can't accept this into the upstream kernel.
> >> > Permissive mode, both per-domain and system-wide, is not intended to
> >> > be a long term solution.  Permissive mode should really only be used
> >> > as a development tool or emergency "hotfix" with the proper solution
> >> > being either an adjustment of the existing policy (SELinux policy
> >> > booleans, labeling changes, etc.) or the development of a new policy
> >> > module which better fits your use case.
> >>
> >> Thanks for the response.
> >> For a system that wants to control a few daemons, is there a
> >> recommended pattern from selinux ?
>
> That is effectively a "targeted" policy model. You target a selection of
> entities and everything else is "unconfined" (ie not targeteed).
>
> An "unconfined" domain is just a process type that has many allow rules
> associated with it making it effectively similar to an "permissive"
> domain. The difference is that since "unconfined" domains have full
> access there should not be any AVC denials (nothing is blocked by
> SELinux because the policy does not target the entity)
>
It seems that my system doesn't have unconfined_t, so
I am trying to get an example.

Can I use a wildcard, something like below ?
type unconfined_t
allow unconfined_t *

An example would be appreciated.

Thanks!
-Jeff



> The stock policy enforced in Red Hat based distributions is a "targeted"
> policy model for example. The unconfined_t domain is one of various
> "unconfined" domains (other examples are unconfined_service_t but
> effectively any type could be made unconfined by simply allowing all accesses.
>
> >
> > Guidance on how to write a SELinux policy for an application is a bit
> > beyond what I have time for in this email, but others on this mailing
> > list might be able to help.  There has definitely been a lot written
> > on the subject, both available online and offline.  My suggestion
> > would be to start "small" with a single SELinux domain for the
> > application and a single type for any configuration, data, or log
> > files it might need; get this initial domain working properly and then
> > you can add increasing levels of access control granularity until
> > you've met your security requirements.  If you've never done this
> > before, go slow, the start might be challenging as you get used to the
> > tools, but you can do it :)
> >
> >> I read this blog about unconfined domain (unconfined_t), maybe this is one way ?
> >> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes
> >
> > It is important to remember that an unconfined domain is, as the name
> > would imply, effectively unconfined by SELinux.  Perhaps this is what
> > you want, but generally speaking if you are running SELinux it is
> > because you have a need or desire for additional access controls
> > beyond the legacy Linux discretionary access controls.
> >
> >> I have two questions on unconfined domain:
> >> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ?
> >
> > Yes.  The SECURITY_SELINUX_DEVELOP kernel build configuration only
> > enables the admin to boot the kernel initially in permissive mode
> > and/or determine the SELinux mode using the "enforcing=X" kernel
> > command line option and a sysfs/securityfs tunable under
> > /sys/fs/selinux/enforce.  The unconfined_t domain is defined purely in
> > the SELinux policy and not the kernel; you could write a SELinux
> > policy without it you wanted, or you could grant unconfined_t-like
> > permissions to multiple different domains in your policy.  It's been a
> > while since I played with it, but I believe the SELinux reference
> > policy (refpol) provides a macro interface to define an arbitrary
> > domain with unconfined_t-like permissions.
> >
> >> 2> will unconfined_t domain log also as permissive domain ?
> >
> > The intent of the unconfined_t domain is that there would be no access
> > denials due to SELinux and thus no AVC audit records related to the
> > unconfined_t domain.  It is not permissive in the sense of the SELinux
> > "mode" (enforcing/permissive/disabled), but it is permissive in the
> > sense that it is given a large number of permissions.
>
> --
> gpg --locate-keys dominick.grift@defensec.nl
> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
> Dominick Grift

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Dominick Grift]

Jeff Xu <jeffxu@chromium.org> writes:

> On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
>>
>> Paul Moore <paul@paul-moore.com> writes:
>>
>> > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote:
>> >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
>> >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
>> >> > >
>> >> > > From: Jeff Xu <jeffxu@chromium.org>
>> >> > >
>> >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
>> >> > > mode, it is useful to disable logging from permissive domain, so audit
>> >> > > log does not get spamed.
>> >> > >
>> >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
>> >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
>> >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
>> >> > > Tested-by: Jeff Xu<jeffxu@chromium.org>
>> >> > > ---
>> >> > >  security/selinux/Kconfig | 10 ++++++++++
>> >> > >  security/selinux/avc.c   |  9 +++++++++
>> >> > >  2 files changed, 19 insertions(+)
>> >> >
>> >> > I'm sorry, but I can't accept this into the upstream kernel.
>> >> > Permissive mode, both per-domain and system-wide, is not intended to
>> >> > be a long term solution.  Permissive mode should really only be used
>> >> > as a development tool or emergency "hotfix" with the proper solution
>> >> > being either an adjustment of the existing policy (SELinux policy
>> >> > booleans, labeling changes, etc.) or the development of a new policy
>> >> > module which better fits your use case.
>> >>
>> >> Thanks for the response.
>> >> For a system that wants to control a few daemons, is there a
>> >> recommended pattern from selinux ?
>>
>> That is effectively a "targeted" policy model. You target a selection of
>> entities and everything else is "unconfined" (ie not targeteed).
>>
>> An "unconfined" domain is just a process type that has many allow rules
>> associated with it making it effectively similar to an "permissive"
>> domain. The difference is that since "unconfined" domains have full
>> access there should not be any AVC denials (nothing is blocked by
>> SELinux because the policy does not target the entity)
>>
> It seems that my system doesn't have unconfined_t, so
> I am trying to get an example.

It does not necessarily have to be unconfined_t.

>
> Can I use a wildcard, something like below ?
> type unconfined_t
> allow unconfined_t *

I took some time to try and come up with an example that goes to the
essence. For this i used the example tiny cil-policy from the SELinux
notebook. You would need `secilc`, `seinfo` and, `sesearch` to try it
out yourself:

curl \
https://raw.githubusercontent.com/SELinuxProject/selinux-notebook/main/src/notebook-examples/cil-policy/cil-policy.cil \
> cil-policy.cil

secilc -vvv cil-policy.cil
seinfo policy.33

this is "tiny CIL policy" it can be used for demonstration.
it has a single type "sys.isid":

seinfo policy.33 -t

and it has only one security class that has two access vector permissions
associated with it namely: "process { dyntransition transition }"

seinfo policy.33 -xc

the single type "sys.isid" has "unconfined" access:

sesearch policy.33 -A

this is essentially the simplest example of an "unconfined" domain.

lets add a new type, and new security class and some permissions. to demonstrate what
it takes to have a unconfined domain in an environment that has more than just one
type, one security class and two permission.

I will do it in stages.

echo '(type mytype) ;; a new type' >> cil-policy.cil
echo '(class myclass ( myperm1 myperm2 )) (classorder (unordered myclass)) ;; a new class with two new permissions' >> cil-policy.cil

secilc -vvv cil-policy.cil
seinfo policy.33
seinfo policy.33 -t
seinfo policy.33 -xc
sesearch policy.33 -A

now type sys.isid is no longer an unconfined domain because it does not have access
to "myclass { myperm1 myperm2 }". The new "mytype" type has no permisssions associated with it at all.

to make sys.isid unconfined again we have to:

1. (allow sys.isid sys.isid (myclass (myperm1 myperm2)))
2. (allow sys.isid mytype (myclass (myperm1 myperm2)))
3. (allow sys.isid mytype (process (dyntransition transition)))

this is a bit hard to manage. we can use type attributes to group types:

echo '(typeattribute mytypes) ;; a new type attribute' >> cil-policy.cil
echo '(typeattributeset mytypes (sys.isid mytype)) ;; all our types are associates' >> cil-policy.cil

secilc -vvv cil-policy.cil
seinfo policy.33 -xamytypes

now the above 3 rules can be written in a simpler way:

echo '(allow sys.isid mytypes (myclass (all))) ;; access to effectively: * myclass *' >> cil-policy.cil
echo '(allow sys.isid mytypes (process (all))) ;; access to effectively: * process *' >> cil-policy.cil

secilc -vvv cil-policy.cil
seinfo policy.33
seinfo policy.33 -t
seinfo policy.33 -xc
sesearch policy.33 -A

I think this is probably the simplest example of an unconfined domain.
type attributes can be used to "organise your policy"
if you plan your policy well then eventually making a "domain" unconfined could be as
easy as associating it with a type attribute.

sesearch policy.33 -A -t sys.isid -t mytypes -dt
seinfo policy.33 -xa mytypes

for example we could create a type attribute called "unconfined_access" and associate
all access vectors with it:

(typeattribute unconfined_access)
(allow unconfined_access mytypes (myclass (all)))
(allow unconfined_access mytypes (process (all)))

then to make type "mytype" unconfined as well; simple associate it with unconfined_access

(typeattributeset unconfined_access (mytype)))

>
> An example would be appreciated.
>
> Thanks!
> -Jeff
>
>
>
>> The stock policy enforced in Red Hat based distributions is a "targeted"
>> policy model for example. The unconfined_t domain is one of various
>> "unconfined" domains (other examples are unconfined_service_t but
>> effectively any type could be made unconfined by simply allowing all accesses.
>>
>> >
>> > Guidance on how to write a SELinux policy for an application is a bit
>> > beyond what I have time for in this email, but others on this mailing
>> > list might be able to help.  There has definitely been a lot written
>> > on the subject, both available online and offline.  My suggestion
>> > would be to start "small" with a single SELinux domain for the
>> > application and a single type for any configuration, data, or log
>> > files it might need; get this initial domain working properly and then
>> > you can add increasing levels of access control granularity until
>> > you've met your security requirements.  If you've never done this
>> > before, go slow, the start might be challenging as you get used to the
>> > tools, but you can do it :)
>> >
>> >> I read this blog about unconfined domain (unconfined_t), maybe this is one way ?
>> >> https://wiki.gentoo.org/wiki/SELinux/Tutorials/What_is_this_unconfined_thingie_and_tell_me_about_attributes
>> >
>> > It is important to remember that an unconfined domain is, as the name
>> > would imply, effectively unconfined by SELinux.  Perhaps this is what
>> > you want, but generally speaking if you are running SELinux it is
>> > because you have a need or desire for additional access controls
>> > beyond the legacy Linux discretionary access controls.
>> >
>> >> I have two questions on unconfined domain:
>> >> 1> Is unconfined_t domain supported in SECURITY_SELINUX_DEVELOP=n mode ?
>> >
>> > Yes.  The SECURITY_SELINUX_DEVELOP kernel build configuration only
>> > enables the admin to boot the kernel initially in permissive mode
>> > and/or determine the SELinux mode using the "enforcing=X" kernel
>> > command line option and a sysfs/securityfs tunable under
>> > /sys/fs/selinux/enforce.  The unconfined_t domain is defined purely in
>> > the SELinux policy and not the kernel; you could write a SELinux
>> > policy without it you wanted, or you could grant unconfined_t-like
>> > permissions to multiple different domains in your policy.  It's been a
>> > while since I played with it, but I believe the SELinux reference
>> > policy (refpol) provides a macro interface to define an arbitrary
>> > domain with unconfined_t-like permissions.
>> >
>> >> 2> will unconfined_t domain log also as permissive domain ?
>> >
>> > The intent of the unconfined_t domain is that there would be no access
>> > denials due to SELinux and thus no AVC audit records related to the
>> > unconfined_t domain.  It is not permissive in the sense of the SELinux
>> > "mode" (enforcing/permissive/disabled), but it is permissive in the
>> > sense that it is given a large number of permissions.
>>
>> --
>> gpg --locate-keys dominick.grift@defensec.nl
>> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
>> Dominick Grift

-- 
gpg --locate-keys dominick.grift@defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Stephen Smalley]

On Mon, Feb 13, 2023 at 1:02 AM Jeff Xu <jeffxu@chromium.org> wrote:
>
> On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift
> <dominick.grift@defensec.nl> wrote:
> >
> > Paul Moore <paul@paul-moore.com> writes:
> >
> > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote:
> > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
> > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
> > >> > >
> > >> > > From: Jeff Xu <jeffxu@chromium.org>
> > >> > >
> > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
> > >> > > mode, it is useful to disable logging from permissive domain, so audit
> > >> > > log does not get spamed.
> > >> > >
> > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
> > >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
> > >> > > Tested-by: Jeff Xu<jeffxu@chromium.org>
> > >> > > ---
> > >> > >  security/selinux/Kconfig | 10 ++++++++++
> > >> > >  security/selinux/avc.c   |  9 +++++++++
> > >> > >  2 files changed, 19 insertions(+)
> > >> >
> > >> > I'm sorry, but I can't accept this into the upstream kernel.
> > >> > Permissive mode, both per-domain and system-wide, is not intended to
> > >> > be a long term solution.  Permissive mode should really only be used
> > >> > as a development tool or emergency "hotfix" with the proper solution
> > >> > being either an adjustment of the existing policy (SELinux policy
> > >> > booleans, labeling changes, etc.) or the development of a new policy
> > >> > module which better fits your use case.
> > >>
> > >> Thanks for the response.
> > >> For a system that wants to control a few daemons, is there a
> > >> recommended pattern from selinux ?
> >
> > That is effectively a "targeted" policy model. You target a selection of
> > entities and everything else is "unconfined" (ie not targeteed).
> >
> > An "unconfined" domain is just a process type that has many allow rules
> > associated with it making it effectively similar to an "permissive"
> > domain. The difference is that since "unconfined" domains have full
> > access there should not be any AVC denials (nothing is blocked by
> > SELinux because the policy does not target the entity)
> >
> It seems that my system doesn't have unconfined_t, so
> I am trying to get an example.
>
> Can I use a wildcard, something like below ?
> type unconfined_t
> allow unconfined_t *
>
> An example would be appreciated.

If your policy in Android-based, then the su domain would be the
easiest starting point. It isn't quite what you want (a permissive
domain with dontaudit rules that suppress all denials, only included
in userdebug or eng builds) but if you replace "dontaudit" with allow
everywhere, it would be "unconfined".

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Stephen Smalley]

On Fri, Feb 17, 2023 at 10:22 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Mon, Feb 13, 2023 at 1:02 AM Jeff Xu <jeffxu@chromium.org> wrote:
> >
> > On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift
> > <dominick.grift@defensec.nl> wrote:
> > >
> > > Paul Moore <paul@paul-moore.com> writes:
> > >
> > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote:
> > > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
> > > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
> > > >> > >
> > > >> > > From: Jeff Xu <jeffxu@chromium.org>
> > > >> > >
> > > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
> > > >> > > mode, it is useful to disable logging from permissive domain, so audit
> > > >> > > log does not get spamed.
> > > >> > >
> > > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> > > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
> > > >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
> > > >> > > Tested-by: Jeff Xu<jeffxu@chromium.org>
> > > >> > > ---
> > > >> > >  security/selinux/Kconfig | 10 ++++++++++
> > > >> > >  security/selinux/avc.c   |  9 +++++++++
> > > >> > >  2 files changed, 19 insertions(+)
> > > >> >
> > > >> > I'm sorry, but I can't accept this into the upstream kernel.
> > > >> > Permissive mode, both per-domain and system-wide, is not intended to
> > > >> > be a long term solution.  Permissive mode should really only be used
> > > >> > as a development tool or emergency "hotfix" with the proper solution
> > > >> > being either an adjustment of the existing policy (SELinux policy
> > > >> > booleans, labeling changes, etc.) or the development of a new policy
> > > >> > module which better fits your use case.
> > > >>
> > > >> Thanks for the response.
> > > >> For a system that wants to control a few daemons, is there a
> > > >> recommended pattern from selinux ?
> > >
> > > That is effectively a "targeted" policy model. You target a selection of
> > > entities and everything else is "unconfined" (ie not targeteed).
> > >
> > > An "unconfined" domain is just a process type that has many allow rules
> > > associated with it making it effectively similar to an "permissive"
> > > domain. The difference is that since "unconfined" domains have full
> > > access there should not be any AVC denials (nothing is blocked by
> > > SELinux because the policy does not target the entity)
> > >
> > It seems that my system doesn't have unconfined_t, so
> > I am trying to get an example.
> >
> > Can I use a wildcard, something like below ?
> > type unconfined_t
> > allow unconfined_t *
> >
> > An example would be appreciated.
>
> If your policy in Android-based, then the su domain would be the
> easiest starting point. It isn't quite what you want (a permissive
> domain with dontaudit rules that suppress all denials, only included
> in userdebug or eng builds) but if you replace "dontaudit" with allow
> everywhere, it would be "unconfined".

BTW SELinux already has a way to achieve the same end as your kernel
patch without any code changes; there are dontaudit rules in policy
that can silence denials and you just need to write them to cover all
classes/permissions. This is done in the Android su policy.

Re: [PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Jeff Xu]

On Fri, Feb 17, 2023 at 7:25 AM Stephen Smalley
<stephen.smalley.work@gmail.com> wrote:
>
> On Fri, Feb 17, 2023 at 10:22 AM Stephen Smalley
> <stephen.smalley.work@gmail.com> wrote:
> >
> > On Mon, Feb 13, 2023 at 1:02 AM Jeff Xu <jeffxu@chromium.org> wrote:
> > >
> > > On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift
> > > <dominick.grift@defensec.nl> wrote:
> > > >
> > > > Paul Moore <paul@paul-moore.com> writes:
> > > >
> > > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@chromium.org> wrote:
> > > > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@paul-moore.com> wrote:
> > > > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@chromium.org> wrote:
> > > > >> > >
> > > > >> > > From: Jeff Xu <jeffxu@chromium.org>
> > > > >> > >
> > > > >> > > When SECURITY_SELINUX_DEVELOP=y and the system is running in permissive
> > > > >> > > mode, it is useful to disable logging from permissive domain, so audit
> > > > >> > > log does not get spamed.
> > > > >> > >
> > > > >> > > Signed-off-by: Jeff Xu <jeffxu@chromium.org>
> > > > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@google.com>
> > > > >> > > Tested-by: Luis Hector Chavez <lhchavez@chromium.org>
> > > > >> > > Tested-by: Jeff Xu<jeffxu@chromium.org>
> > > > >> > > ---
> > > > >> > >  security/selinux/Kconfig | 10 ++++++++++
> > > > >> > >  security/selinux/avc.c   |  9 +++++++++
> > > > >> > >  2 files changed, 19 insertions(+)
> > > > >> >
> > > > >> > I'm sorry, but I can't accept this into the upstream kernel.
> > > > >> > Permissive mode, both per-domain and system-wide, is not intended to
> > > > >> > be a long term solution.  Permissive mode should really only be used
> > > > >> > as a development tool or emergency "hotfix" with the proper solution
> > > > >> > being either an adjustment of the existing policy (SELinux policy
> > > > >> > booleans, labeling changes, etc.) or the development of a new policy
> > > > >> > module which better fits your use case.
> > > > >>
> > > > >> Thanks for the response.
> > > > >> For a system that wants to control a few daemons, is there a
> > > > >> recommended pattern from selinux ?
> > > >
> > > > That is effectively a "targeted" policy model. You target a selection of
> > > > entities and everything else is "unconfined" (ie not targeteed).
> > > >
> > > > An "unconfined" domain is just a process type that has many allow rules
> > > > associated with it making it effectively similar to an "permissive"
> > > > domain. The difference is that since "unconfined" domains have full
> > > > access there should not be any AVC denials (nothing is blocked by
> > > > SELinux because the policy does not target the entity)
> > > >
> > > It seems that my system doesn't have unconfined_t, so
> > > I am trying to get an example.
> > >
> > > Can I use a wildcard, something like below ?
> > > type unconfined_t
> > > allow unconfined_t *
> > >
> > > An example would be appreciated.
> >
> > If your policy in Android-based, then the su domain would be the
> > easiest starting point. It isn't quite what you want (a permissive
> > domain with dontaudit rules that suppress all denials, only included
> > in userdebug or eng builds) but if you replace "dontaudit" with allow
> > everywhere, it would be "unconfined".
>
> BTW SELinux already has a way to achieve the same end as your kernel
> patch without any code changes; there are dontaudit rules in policy
> that can silence denials and you just need to write them to cover all
> classes/permissions. This is done in the Android su policy.

Got it, Thanks everyone for pointing out solutions!

-Jeff