Re: [MAINTAINERS SUMMIT] re-think of richACLs in AI/LLM era

["Coly Li" <colyli@fnnas.com>]

On Wed, Sep 10, 2025 at 03:11:55PM +0800, Paul Moore wrote:
> On Wed, Sep 10, 2025 at 9:32 AM Coly Li <colyli@fnnas.com> wrote:
> > On Mon, Sep 08, 2025 at 09:03:24PM +0800, Paul Moore wrote:
> 
> ...
> 
> > > I can't say I'm familiar with the RichACL concept, but generally
> > > speaking yes, the LSM framework exists as a way to implement access
> > > control mechanisms beyond the traditional Linux access controls (other
> > > things too, but those aren't really relevant here).
> >
> > Is it convenient for normal users or non-root processes (including the policy agent) to
> > setup the LSM rules? We need to allow normal users to set their own access control policy
> > for the data they owned.
> 
> Management of an individual LSM's configuration is generally left to
> the individual LSM.  Some LSMs restrict their configuration knobs
> behind capabilities or their own access controls, while others allow
> unprivileged access to the configuration; it depends on the LSM's
> security model.  As an unprivileged example, Landlock allows
> applications, run by arbitrary users, to set their own Landlock
> security policy via the Landlock API.
> 

I forward the suggestion to our application team, and they try to evaluate
and replied the result.

Currently they are using bpf to do the access control rules checking, and
LSM access control method e.g. Landlock is quite similar to a rules based
control method. They still need to persist all the rules on disk, and load
the rules during system initlization time. When the number of rules increased,
the maintennance is complicated and slow.

Also the application team give me a use case, ask how to achieve the access
control effiently. Let me describe by the followed text.

Users store they photos on the system, and the compact AI module processes all
their photos and groups all the photos into different categories like pizza,
dogs, cats, foods or group photos. After the process done, users may see they
photos in different categories that the AI module thinks they should be in. Then
users may share the categories with photos to others. If indentical categories
shared by different users, the shared photos can be combined all together. And
AI module may continue to process the shared photos and generate new categaries
from the shared photos, e.g. pizza in the same city, cats and dogs in closed
location, group photos contains the most common people, etc. Now the differet
categories are implemented by different directories in the publicly shared
directory.

In each category directory, photos with a category (or attribution) can be
accessed as hard links to the original photo inodes and share the identical
inodes. All these category directories are created by the AI module, although
the photos are shared from each users. If a user is identified from a group
photo, and this user is noticed that the photo is publicly shared. If this user
doesn't want his face to be shared in public, for an optinal privacy protection
right, this user can remove the hardlink of the photo which his or her face is
in, that is he or she can remove the hardlink (dentry) under a publicly shared
directory which this user doesn't have write permission. Because this user can
be idnetified as owner of his or her face, and the photo has his face in, he or
she should have write permission to delete the photo, but no write permission to
other photos in same category directioy which his or her face is not in.

The above example is one of the simple case just for photos processing and
sharing in the AI context. The rules of access control are created or destoried
dynamically and maybe only exist for a short period. And the number of rules are
quite large.

Current rules based access control is inefficient and complicated to implement
for the above simple case, and the application team replies they don't see the
rules based LSM method can make it be more simple.

> > Also there is a special case, e.g. a file’s parent directory doesn’t allow write
> > permission, but the file needs to grant delete permission.
> > 4614 int do_unlinkat(int dfd, struct filename *name)
> > 4615 {
> > [snipped]
> > 4645                 inode = dentry->d_inode;
> > 4646                 ihold(inode);
> > 4647                 error = security_path_unlink(&path, dentry);
> > 4648                 if (error)
> > 4649                         goto exit3;
> > 4650                 error = vfs_unlink(mnt_idmap(path.mnt), path.dentry->d_inode,
> > 4651                                    dentry, &delegated_inode);
> > [snipped]
> > 4563 int vfs_unlink(struct mnt_idmap *idmap, struct inode *dir,
> > 4564                struct dentry *dentry, struct inode **delegated_inode)
> > 4565 {
> > 4566         struct inode *target = dentry->d_inode;
> > 4567         int error = may_delete(idmap, dir, dentry, 0);
> > 4568
> > 4569         if (error)
> > 4570                 return error;
> > [snipped]
> >
> > It seems in do_unlinkat() the security check security_path_unlink() is called before
> > calling may_delete() inside vfs_unlink(). So even security rule permits to delete
> > this file but the parent directory doesn't grant write permission, such access control
> > still cannot be archieved.
> 
> One of the important parts of the LSM framework as a whole is that
> LSMs can not grant access that would otherwise be blocked by the
> standard/discretionary access controls built into the Linux kernel; in
> other words, LSMs can only say "no" to an access, they can not grant
> access by themselves.  Yes, this is by design, and no, I see no reason
> to change that design decision at this point in time (doing so would
> require a tremendous amount of work and likely introduce a fair number
> of security regressions for quite some time).

I understand and agree the concern of security. But the reality is more and more
similar or relative access control requirements will sprint up from the AI/LLM
applications and use cases. We just want to solve the access control challenge,
and the LSM rules based methods are not easy for application developers.

Forgive me for the late response, because I wait for the feed back from our
application development teams.

Thanks.

Coly Li