linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Sebastien Buisson <sbuisson.ddn@gmail.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: Paul Moore <pmoore@redhat.com>,
	selinux@tycho.nsa.gov, william.c.roberts@intel.com,
	linux-kernel@vger.kernel.org,
	linux-security-module@vger.kernel.org,
	Sebastien Buisson <sbuisson@ddn.com>,
	james.l.morris@oracle.com
Subject: Re: [PATCH] selinux: add selinux_is_enforced() function
Date: Wed, 12 Apr 2017 19:07:09 +0200	[thread overview]
Message-ID: <CAPkE-bWrxxtcb5bUpSV07CUBGGxMt7y+OrAd9Qvk0o4-Lo26VA@mail.gmail.com> (raw)
In-Reply-To: <1492014294.3881.14.camel@tycho.nsa.gov>

2017-04-12 18:24 GMT+02:00 Stephen Smalley <sds@tycho.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?

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

  reply	other threads:[~2017-04-12 17:08 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-12  9:06 [PATCH] selinux: add selinux_is_enforced() function Sebastien Buisson
2017-04-12 11:55 ` Paul Moore
2017-04-12 13:30   ` Sebastien Buisson
2017-04-12 13:58     ` Stephen Smalley
2017-04-12 15:19       ` Sebastien Buisson
2017-04-12 16:33         ` Stephen Smalley
2017-04-13  0:12           ` Casey Schaufler
2017-04-12 13:30   ` Sebastien Buisson
2017-04-12 14:35     ` Stephen Smalley
2017-04-12 15:11       ` Sebastien Buisson
2017-04-12 16:24         ` Stephen Smalley
2017-04-12 17:07           ` Sebastien Buisson [this message]
2017-04-12 17:24             ` Stephen Smalley
2017-04-12 12:13 ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAPkE-bWrxxtcb5bUpSV07CUBGGxMt7y+OrAd9Qvk0o4-Lo26VA@mail.gmail.com \
    --to=sbuisson.ddn@gmail.com \
    --cc=james.l.morris@oracle.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-security-module@vger.kernel.org \
    --cc=pmoore@redhat.com \
    --cc=sbuisson@ddn.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    --cc=william.c.roberts@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).