linux-kernel - Re: [PATCH 2/3] lsm: introduce security_lsm_manage

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <75c7424b-fec9-469b-8f73-50ab86948a24@I-love.SAKURA.ne.jp>
Date: Fri, 9 May 2025 00:07:48 +0900
From: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>
To: John Johansen <john.johansen@...onical.com>,
        Maxime Bélair <maxime.belair@...onical.com>,
        linux-security-module@...r.kernel.org
Cc: paul@...l-moore.com, jmorris@...ei.org, serge@...lyn.com, mic@...ikod.net,
        kees@...nel.org, stephen.smalley.work@...il.com,
        casey@...aufler-ca.com, takedakn@...data.co.jp,
        linux-api@...r.kernel.org, apparmor@...ts.ubuntu.com,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH 2/3] lsm: introduce security_lsm_manage_policy hook

On 2025/05/08 23:44, John Johansen wrote:
> On 5/8/25 05:55, Tetsuo Handa wrote:
>> On 2025/05/08 17:25, John Johansen wrote:
>>> That is fine. But curious I am curious what the interface would look like to fit TOMOYO's
>>> needs.
>>
>> Stream (like "FILE *") with restart from the beginning (like rewind(fp)) support.
>> That is, the caller can read/write at least one byte at a time, and written data
>> is processed upon encountering '\n'.
>>
> 
> that can be emulated within the current sycall, where the lsm maintains a buffer.

That cannot be emulated, for there is no event that is automatically triggered when
the process terminates (i.e. implicit close() upon exit()) in order to release the
buffer the LSM maintains.

> Are you asking to also read data back out as well, that could be added, but doing
> a syscall per byte here or through the fs is going to have fairly high overhead.

At least one byte means arbitrary bytes; that is, the caller does not need to read
or write the whole policy at one syscall.

> 
> Without understanding the requirement it would seem to me, that it would be
> better to emulate that file buffer manipulation in userspace similar say C++
> stringstreams, and then write the syscall when done.

The size of the whole policy in byte varies a lot.