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]
Message-ID: <2ad46d79-6e81-998d-3d8b-ed26c3d52a95@schaufler-ca.com>
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.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ