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