Re: [PATCH -next 0/5] landlock: add chmod and chown support

[Günther Noack]

On Mon, Aug 22, 2022 at 12:35:18PM -0700, Casey Schaufler wrote:
> On 8/22/2022 12:17 PM, Günther Noack wrote:
> > Hi!
> >
> > Very exciting to see! Thank you for sending this! :)
> >
> > I'm just throwing in some comments based on the very similar truncate
> > patch set, in the hope that it helps. (But obviously, Mickaël Salaün
> > has the last word on this code.)
> >
> > Slightly higher level question: Should we start to group the
> > functionality of multiple LSM hooks under one Landlock flag? (Will it
> > be harder to change the LSM hook interface in the future if we
> > continue to add one flag per hook? Or is this structure already
> > exposed to userspace by other LSMs?)
>
> I'm not a landlock expert. The question is nonsensical, yet somewhat
> frightening nonetheless. Could you put just a touch more context into
> what you're asking for?

By "Landlock flags", I meant the integer that Landlock uses to
represent the set of possible operations on a file hierarchy:

Landlock's file system access rights (access_mode_t on the kernel
side) are defined with an integer with flags (LANDLOCK_ACCESS_FS_*)
for different operations that one might do with files. They get used
from userspace to control what is permitted on which parts of the file
system. (Docs: https://docs.kernel.org/userspace-api/landlock.html)

Currently most of the available Landlock flags map pretty closely to
one of the file- and path-related LSM hooks. (See various hook
implementations in security/landlock/fs.c)

The file system operations that Landlock doesn't cover yet (as of
kernel 5.19) are listed below, and there are potentially a few more
that might be missing. I suspect/hope that there will be more patches
in the style of the truncate/chmod/chown patches, which will add that
coverage.

The question is basically:
When these patches get added, how should the userspace-exposed
Landlock file system access rights map to the LSM hooks for these
upcoming Landlock features? Should each of the newly covered
operations have its own flag, or is it better to group them?

(It's well possible that the right answer is "one flag per feature",
but I feel it still makes sense to ask this before all these patches
get written?)

—Günther

> > For example, some of the "missing" operations listed on the Landlock
> > documentation could also be grouped roughly as:
> >
> > Modifying files:
> >  - truncate
> >
> > Modifying file metadata:
> >  - chmod
> >  - chown
> >  - setxattr
> >  - utime
> >
> > Observing files (check presence and file metadata):
> >  - access
> >  - stat
> >  - readlink, following links (can observe symlink presence)
> >  - chdir (can observe dir presence and 'x' attribute)
> >
> > Ungrouped:
> >  - flock
> >  - ioctl
> >  - fcntl
> >
> > Do you have opinions on this?
> >
> > —Günther
> >
> > On Mon, Aug 22, 2022 at 07:46:56PM +0800, Xiu Jianfeng wrote:
> >> hi,
> >>   this patchset adds chmod and chown support for landlock
> >>
> >> Xiu Jianfeng (5):
> >>   landlock: expand access_mask_t to u32 type
> >>   landlock: add chmod and chown support
> >>   landlock/selftests: add selftests for chmod and chown
> >>   landlock/samples: add chmod and chown support
> >>   landlock: update chmod and chown support in document
> >>
> >>  Documentation/userspace-api/landlock.rst     |   8 +-
> >>  include/uapi/linux/landlock.h                |   8 +-
> >>  samples/landlock/sandboxer.c                 |  12 +-
> >>  security/landlock/fs.c                       |  16 +-
> >>  security/landlock/limits.h                   |   2 +-
> >>  security/landlock/ruleset.h                  |   2 +-
> >>  security/landlock/syscalls.c                 |   2 +-
> >>  tools/testing/selftests/landlock/base_test.c |   2 +-
> >>  tools/testing/selftests/landlock/fs_test.c   | 234 ++++++++++++++++++-
> >>  9 files changed, 274 insertions(+), 12 deletions(-)
> >>
> >> --
> >> 2.17.1
> >>
> > --

--