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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <88d70234-2c43-4208-88c2-15a39aa5c6eb@canonical.com>
Date: Thu, 8 May 2025 20:25:04 -0700
From: John Johansen <john.johansen@...onical.com>
To: Tetsuo Handa <penguin-kernel@...ove.SAKURA.ne.jp>,
 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 5/8/25 08:07, Tetsuo Handa wrote:
> 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.
>

security_task_free()
  
>> 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.
> 
got it

>>
>> 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.
> 
sure, buffers can be variable length. AppArmor policy also varies a lot in size.

More than anything I am trying to understand TOMOYO's requirements. They do
align better with using an fs interface. Can they be met sure, but it would
be more work for TOMOYO.

One of the big motivations for the syscall from the apparmor side is getting
away from the need to have the vfs present or having to pass an fd into the
environment.