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 for Android: free password hash cracker in your pocket

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

Message-ID: <1492014294.3881.14.camel@tycho.nsa.gov>
Date:   Wed, 12 Apr 2017 12:24:54 -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 17:11 +0200, Sebastien Buisson wrote:
> 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.

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.

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

In SELinux, the underlying kernel function is security_read_policy();
you'd have to wrap it with a LSM hook interface, and generalize it a
bit wrt whether to use vmalloc_user() or not.

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