[PATCH 1/1] Add CONFIG_SECURITY_SELINUX_PERMISSIVE_DONTAUDIT

[Dominick Grift]

Jeff Xu <jeffxu at chromium.org> writes:

> On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift
> <dominick.grift at defensec.nl> wrote:
>>
>> 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)
>>
> 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 at defensec.nl
>> Key fingerprint = FCD2 3660 5D6B 9D27 7FC6  E0FF DA7E 521F 10F6 4098
>> Dominick Grift

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