[PATCH 0/1] process attribute support for Landlock

[Casey Schaufler]

On 3/6/2023 2:40 PM, Shervin Oloumi wrote:
>> Emphasis: DO NOT USE /proc/.../attr/current! Seriously!
>>
>> I made a huge mistake reusing current in Smack. If you want to
>> provide a Landlock attribute in /proc create a new one. Long term
>> we're trying to move to a syscall interface (patches in review).
>> But for the time being (and backports) a new name in attr is easy
>> enough to do and will avoid many headaches. Better yet, a subdirectory
>> in attr - /proc/.../attr/landlock - will avoid all sorts of issues.
> Thanks for flagging this. Creating a new directory and attribute name
> for this makes sense, but you can still only interact with process
> attributes of a single LSM on the system right? Just want to make sure
> my understanding is correct, because even when Landlock uses a
> different name and a new subdirectory for this, still the kernel only
> calls the hook function of the first LSM on the list (Landlock in our
> case). So reading proc/.../attr/current or any other attribute besides
> /proc/.../attr/landlock/some_attribute would result in EINVAL if
> Landlock was first on the CONFIG_LSM list.

That's true, but we've been able to move parts of the general stacking
process forward when there's a specific need for them. In this case we'd
need changes for security_[gs]etprocattr() that are already understood.