[PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Dominick Grift]

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

> 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 ?

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 at defensec.nl
Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
Dominick Grift