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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAPkE-bWQLfSq0+J0uoMRKAPbSdO0giuGZzfRXA7VXL+xo3fNgg@mail.gmail.com>
Date:   Wed, 12 Apr 2017 17:11:43 +0200
From:   Sebastien Buisson <sbuisson.ddn@...il.com>
To:     Stephen Smalley <sds@...ho.nsa.gov>
Cc:     Paul Moore <pmoore@...hat.com>, selinux@...ho.nsa.gov,
        william.c.roberts@...el.com, linux-kernel@...r.kernel.org,
        linux-security-module@...r.kernel.org,
        Sebastien Buisson <sbuisson@....com>, james.l.morris@...cle.com
Subject: Re: [PATCH] selinux: add selinux_is_enforced() function

2017-04-12 16:35 GMT+02:00 Stephen Smalley <sds@...ho.nsa.gov>:
> How are you using this SELinux information in the kernel and/or in
> userspace?  What's the purpose of it?  What are you comparing it
> against?  Why do you care if it changes?

Enforcement status and policy version are compared to their previously
stored value. If they differ, then it means we need to call a userland
helper from Lustre client kernelspace to read the currently loaded
policy (reading it will let us know if the Lustre client node is
conforming to the Lustre-wide security policy).
As calling the userland helper is costly, we do it only when it is
necessary by retrieving some SELinux key information directly from
kernelspace.

> Note btw that the notion of a policy name/type and the policy file path
> is purely a userspace construct and shouldn't be embedded in your
> kernel code.  Android for example doesn't follow that convention at
> all; their SELinux policy file is simply /sepolicy.  On modern kernels,
> you can always read the currently loaded policy from the kernel itself
> via /sys/fs/selinux/policy (formerly just /selinux/policy).

As I understand it, a userspace program can directly read the policy
info exposed by the kernel by reading this file. But how about reading
it from kernelspace?