[PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Paul Moore]

On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu at chromium.org> wrote:
> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul at paul-moore.com> wrote:
> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu at chromium.org> wrote:
> > >
> > > From: Jeff Xu <jeffxu at 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 at chromium.org>
> > > Signed-off-by: Luis Hector Chavez <lhchavez at google.com>
> > > Tested-by: Luis Hector Chavez <lhchavez at chromium.org>
> > > Tested-by: Jeff Xu<jeffxu at 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