Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1622295

Re: [PATCH] selinux: add selinux_is_enforced() function

From Stephen Smalley <sds@tycho.nsa.gov>
Newsgroups linux.kernel
Subject Re: [PATCH] selinux: add selinux_is_enforced() function
Date 2017-04-12 18:30 +0200
Message-ID <tvtjz-6IX-9@gated-at.bofh.it> (permalink)
References <tvmrM-2Do-29@gated-at.bofh.it> <tvp6h-3Zp-11@gated-at.bofh.it> <tvqF4-51n-31@gated-at.bofh.it> <tvrB9-5Bn-33@gated-at.bofh.it> <tvsdP-64C-13@gated-at.bofh.it>
Organization National Security Agency

Show all headers | View raw


On Wed, 2017-04-12 at 17:11 +0200, Sebastien Buisson wrote:
> 2017-04-12 16:35 GMT+02:00 Stephen Smalley <sds@tycho.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.

Back to linux.kernel | Previous | NextPrevious in thread | Next in thread | Find similar | Unroll thread


Thread

[PATCH] selinux: add selinux_is_enforced() function Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-04-12 11:10 +0200
  Re: [PATCH] selinux: add selinux_is_enforced() function Paul Moore <pmoore@redhat.com> - 2017-04-12 14:00 +0200
    Re: [PATCH] selinux: add selinux_is_enforced() function Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-04-12 15:40 +0200
      Re: [PATCH] selinux: add selinux_is_enforced() function Stephen Smalley <sds@tycho.nsa.gov> - 2017-04-12 16:40 +0200
        Re: [PATCH] selinux: add selinux_is_enforced() function Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-04-12 17:20 +0200
          Re: [PATCH] selinux: add selinux_is_enforced() function Stephen Smalley <sds@tycho.nsa.gov> - 2017-04-12 18:30 +0200
            Re: [PATCH] selinux: add selinux_is_enforced() function Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-04-12 19:10 +0200
              Re: [PATCH] selinux: add selinux_is_enforced() function Stephen Smalley <sds@tycho.nsa.gov> - 2017-04-12 19:30 +0200
    Re: [PATCH] selinux: add selinux_is_enforced() function Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-04-12 15:40 +0200
      Re: [PATCH] selinux: add selinux_is_enforced() function Stephen Smalley <sds@tycho.nsa.gov> - 2017-04-12 16:00 +0200
        Re: [PATCH] selinux: add selinux_is_enforced() function Sebastien Buisson <sbuisson.ddn@gmail.com> - 2017-04-12 17:30 +0200
          Re: [PATCH] selinux: add selinux_is_enforced() function Stephen Smalley <sds@tycho.nsa.gov> - 2017-04-12 18:30 +0200
            Re: [PATCH] selinux: add selinux_is_enforced() function Casey Schaufler <casey@schaufler-ca.com> - 2017-04-13 02:20 +0200
  Re: [PATCH] selinux: add selinux_is_enforced() function Stephen Smalley <sds@tycho.nsa.gov> - 2017-04-12 14:10 +0200

csiph-web