linux-kernel - Re: [PATCH v6 1/2] selinux: add brief info to policydb

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]

Message-ID: <CAPkE-bXeTJhD+CXFVpzBGWuAvsddTX+6gkRrmqZE69yu2Vwrtg@mail.gmail.com>
Date:   Wed, 24 May 2017 17:26:20 +0200
From:   Sebastien Buisson <sbuisson.ddn@...il.com>
To:     Paul Moore <paul@...l-moore.com>
Cc:     Stephen Smalley <sds@...ho.nsa.gov>,
        James Morris <james.l.morris@...cle.com>,
        linux-security-module@...r.kernel.org,
        Sebastien Buisson <sbuisson@....com>,
        linux-kernel@...r.kernel.org, selinux@...ho.nsa.gov
Subject: Re: [PATCH v6 1/2] selinux: add brief info to policydb

2017-05-23 21:11 GMT+02:00 Paul Moore <paul@...l-moore.com>:
> On Tue, May 23, 2017 at 12:29 PM, Sebastien Buisson
> <sbuisson.ddn@...il.com> wrote:
>> Another way could be to add another hook to check policy brief info
>> validity. It would take a string as an input parameter, and return 0
>> if it matches the current policy. So Lustre client code would
>> systematically call this hook, and only call security_policydb_brief()
>> when the policy has changed, to store the current value internally.
>
> I'm not sure I like this approach as much as the one above, for a
> variety of reasons.  Is this option more desirable from a Lustre point
> of view?

It is true that now that the notification code is present in the
selinux/next branch, it is worth using it. I was thinking, but I may
be wrong, that future inclusion of this series of patches in some
distributions' kernels like CentOS or RedHat would be easier if it did
not have dependencies on other patches. This is why I thought about an
alternative solution.
Technically speaking, the solution based on notifications can fit the
Lustre needs, letting Lustre maintain its own sequence number as you
suggest.

Sebastien.