linux-kernel - Re: [PATCH] selinux: add selinux_is

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Wed, 12 Apr 2017 17:12:13 -0700
From:   Casey Schaufler <casey@...aufler-ca.com>
To:     Stephen Smalley <sds@...ho.nsa.gov>,
        Sebastien Buisson <sbuisson.ddn@...il.com>
Cc:     james.l.morris@...cle.com, william.c.roberts@...el.com,
        linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Sebastien Buisson <sbuisson@....com>, selinux@...ho.nsa.gov
Subject: Re: [PATCH] selinux: add selinux_is_enforced() function

On 4/12/2017 9:33 AM, Stephen Smalley wrote:
> On Wed, 2017-04-12 at 17:19 +0200, Sebastien Buisson wrote:
>> 2017-04-12 15:58 GMT+02:00 Stephen Smalley <sds@...ho.nsa.gov>:
>>> Even your usage of selinux_is_enabled() looks suspect; that should
>>> probably go away.  Only other user of it seems to be some cred
>>> validity
>>> checking that could be dropped as well.
>> Well the main reason for calling selinux_is_enabled() is performance
>> optimization.
>> Should I propose a patch to add a new security_is_enabled() function
>> at the LSM abstraction layer? Or do you consider we should not test
>> security enabled at all?
> It isn't clear what "is enabled" means in general, particularly with
> stacking. I would either drop it or replace it with a LSM hook that is
> more precise.  For example, NFSv4 introduced a security_ismaclabel()
> hook so that it could test whether a given security.* xattr is a MAC
> label.

You can determine what security modules are enabled
by reading /sys/kernel/security/lsm in userspace (4.11 feature).

Your kernel code *really* shouldn't care what security
modules are enabled. If you do care, you've designed poorly.
If you're trying to ensure consistent policy between members
of your cluster you're better off doing that in user space
than in the kernel.

>
> _______________________________________________
> Selinux mailing list
> Selinux@...ho.nsa.gov
> To unsubscribe, send email to Selinux-leave@...ho.nsa.gov.
> To get help, send an email containing "help" to Selinux-request@...ho.nsa.gov.