[PATCH v2] lsm: adds process attribute getter for Landlock

[Mickaël Salaün]

On 23/05/2023 23:12, Paul Moore wrote:
> On Tue, May 23, 2023 at 2:13 AM Jeff Xu <jeffxu at chromium.org> wrote:
>> On Mon, May 22, 2023 at 12:56 PM Paul Moore <paul at paul-moore.com> wrote:
>>> On Thu, May 18, 2023 at 5:26 PM Casey Schaufler <casey at schaufler-ca.com> wrote:
>>>> On 5/18/2023 1:45 PM, Shervin Oloumi wrote:
>>>>> Adds a new getprocattr hook function to the Landlock LSM, which tracks
>>>>> the landlocked state of the process. This is invoked when user-space
>>>>> reads /proc/[pid]/attr/domain
>>>>
>>>> Please don't add a Landlock specific entry directly in the attr/
>>>> directory. Add it only to attr/landlock.
>>>>
>>>> Also be aware that the LSM maintainer (Paul Moore) wants to move
>>>> away from the /proc/.../attr interfaces in favor of a new system call,
>>>> which is in review.
>>>
>>> What Casey said above.
>>>
>>> There is still some uncertainty around timing, and if we're perfectly
>>> honest, acceptance of the new syscalls at the Linus level, but yes, I
>>> would very much like to see the LSM infrastructure move away from
>>> procfs and towards a syscall API.  Part of the reasoning is that the
>>> current procfs API is ill-suited to handle the multiple, stacked LSMs
>>> and the other part being the complexity of procfs in a namespaced
>>> system.  If the syscall API is ultimately rejected, we will need to
>>> revisit the idea of a procfs API, but even then I think we'll need to
>>> make some changes to the current approach.
>>>
>>> As I believe we are in the latter stages of review for the syscall
>>> API, perhaps you could take a look and ensure that the current
>>> proposed API works for what you are envisioning with Landlock?

I agree, and since the LSM syscalls are almost ready that should not 
change much the timing. In fact, extending these syscalls might be 
easier than tweaking the current procfs/attr API for Landlock specific 
requirements (e.g. scoped visibility). We should ensure that these 
syscalls would be a good fit to return file descriptors, but in the 
short term we only need to know if a process is landlocked or not, so a 
raw return value (0 or -errno) will be enough.

Mentioning in the LSM syscalls patch series that they may deal with (and 
return) file descriptors could help API reviewers though.


>>>
>> Which review/patch to look for the proposed API ?
> 
> See Casey's reply if you haven't already.  You can also find the LSM
> list archived on lore.kernel.org; that is probably the best way to
> track LSM development if you don't want to subscribe to the list.
> 
> * https://lore.kernel.org/linux-security-module
> 
>> I guess ChromeOS will need to backport to 5.10 when the proposal is accepted.
> 
> Maybe?  Distro specific backports aren't generally on-topic for the
> upstream Linux mailing lists, especially large commercial distros with
> plenty of developers to take care of things like that.
> 

Backporting the LSM syscall patch series will create conflicts but they 
should be manageable and the series should be quite standalone. You'll 
need to understand the changes to get a clean backport, so reviewing the 
current proposal is a good opportunity to be ready and to catch 
potential future issues.