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]

Date:   Wed, 12 Apr 2017 13:24:55 -0400
From:   Stephen Smalley <sds@...ho.nsa.gov>
To:     Sebastien Buisson <sbuisson.ddn@...il.com>
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

On Wed, 2017-04-12 at 19:07 +0200, Sebastien Buisson wrote:
> 2017-04-12 18:24 GMT+02:00 Stephen Smalley <sds@...ho.nsa.gov>:
> > Maybe you want to register a notifier callback on policy reload?
> > See
> > the archives for the SELinux support for Infiniband RDMA patches
> > (which
> > seem to have stalled), which included LSM hooks and SELinux
> > implementation to support notifications on policy reloads.
> 
> I need to have a look indeed. So it is a callback in kernelspace?

Yes, see:
https://patchwork.kernel.org/patch/9443417/

> 
> > > 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?
> > 
> > This seems very inefficient though for your purposes.  Wouldn't it
> > be
> > better to just extend SELinux to compute the checksum from the
> > original
> > image when the policy is loaded, save that checksum in the
> > policydb,
> > and provide you with a way to fetch the already computed
> > checksum?  The
> > computation would be done in security_load_policy() and saved in
> > the
> > policydb.  Then you could introduce a function and a LSM hook to
> > export
> > it to your code. We would probably want to also expose it via a
> > selinuxfs node to userspace.
> 
> This is an excellent suggestion. It makes much more sense to have the
> checksum computed on SELinux side when a policy is loaded. And then
> just read this checksum when needed, both from kernel and userspace.
>
> > This however only works for checking that you have a completely
> > identical policy built in exactly the same way.  You could have
> > semantically identical policies that still differ in the binary
> > policy
> > file, or policies with minor local customizations that aren't
> > significant.  But perhaps that isn't an issue for Lustre
> > environments.
> 
> If we can protect against local customizations this is great. What
> could be the other scenario leading to different binary policies
> while
> being semantically identical?

There can be ordering or optimization differences, depending on the
policy compiler toolchain and build process. Probably not a concern if
they are all running the same distro with the same policy package,
built in the same build environment.