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 19:07:09 +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 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?

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