On Fri, Sep 23, 2022 at 11:45 AM Dominick Grift <dominick.grift@xxxxxxxxxxx> wrote: > > Paul Moore <paul@xxxxxxxxxxxxxx> writes: > > > On Fri, Sep 23, 2022 at 1:43 PM Jeff Xu <jeffxu@xxxxxxxxxxxx> wrote: > >> On Wed, Sep 21, 2022 at 12:11 PM Paul Moore <paul@xxxxxxxxxxxxxx> wrote: > >> > On Wed, Sep 21, 2022 at 2:54 PM <jeffxu@xxxxxxxxxxxx> wrote: > >> > > > >> > > From: Jeff Xu <jeffxu@xxxxxxxxxxxx> > >> > > > >> > > 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@xxxxxxxxxxxx> > >> > > Signed-off-by: Luis Hector Chavez <lhchavez@xxxxxxxxxx> > >> > > Tested-by: Luis Hector Chavez <lhchavez@xxxxxxxxxxxx> > >> > > Tested-by: Jeff Xu<jeffxu@xxxxxxxxxxxx> > >> > > --- > >> > > 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@xxxxxxxxxxx > Key fingerprint = FCD2 3660 5D6B 9D27 7FC6 E0FF DA7E 521F 10F6 4098 > Dominick Grift
