linux-kernel - Re: [PATCH v5 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] [day] [month] [year] [list]

Message-ID: <CAFftDdqh_7DW9zXvSA3isCXMDRNghaOMHJ5UQQJFYTTB8xf3ug@mail.gmail.com>
Date:   Wed, 17 May 2017 11:28:16 -0700
From:   William Roberts <bill.c.roberts@...il.com>
To:     Sebastien Buisson <sbuisson.ddn@...il.com>
Cc:     Stephen Smalley <sds@...ho.nsa.gov>,
        "selinux@...ho.nsa.gov" <selinux@...ho.nsa.gov>,
        "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        linux-security-module@...r.kernel.org,
        Sebastien Buisson <sbuisson@....com>,
        James Morris <james.l.morris@...cle.com>
Subject: Re: [PATCH v5 1/2] selinux: add brief info to policydb

On Wed, May 17, 2017 at 10:00 AM, Sebastien Buisson
<sbuisson.ddn@...il.com> wrote:
> 2017-05-17 18:04 GMT+02:00 William Roberts <bill.c.roberts@...il.com>:
>> I'm assuming in the Lustre code you're going to call security_policy_brief(),
>> how would the caller know how big that buffer is going to be?
>
> We can determine it at configure time for instance, given that len as
> an output parameter would give the size necessary to store the policy
> brief info.
>
>> I'm looking at both v5 patches, I don't see where it's being called with alloc
>> set to false.
>
> It would be called with alloc set to false from network and
> distributed file systems like Lustre.

That doesn't seem like a good way at all.
1. What happens as the brief is changed, all callers with false
    would potentially need there buffer size increased.
2. There is no guarantee at runtime that as brief changes,
    that the size will remain bounded. fields could be
    added/changed/removed.
3. If/when stacking needs to be supported, brief size can
    change dramatically, bringing us back to issue 1.

-- 
Respectfully,

William C Roberts