Skip to content

seccomp: add support for Landlock syscalls in default policy #43199

Merged
thaJeztah merged 1 commit into
moby:masterfrom
Xyene:allow-landlock
May 13, 2022
Merged

seccomp: add support for Landlock syscalls in default policy #43199
thaJeztah merged 1 commit into
moby:masterfrom
Xyene:allow-landlock

Conversation

@Xyene

@Xyene Xyene commented Jan 30, 2022

Copy link
Copy Markdown
Contributor

This commit allows the landlock system call in the default seccomp
policy.

Landlock was introduced in kernel 5.13, to fill the gap that
inspecting filepaths passed as arguments to filesystem system calls is
not really possible with pure seccomp (unless involving ptrace).

Allowing landlock by default fits in with allowing seccomp, for
containerized applications to voluntarily restrict their access rights
to files within the container.

@Xyene

Xyene commented Jan 30, 2022

Copy link
Copy Markdown
Contributor Author

(CI failure appears unrelated, please correct me if wrong.)

@tonistiigi tonistiigi left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@AkihiroSuda

Copy link
Copy Markdown
Member

Maybe we should add all recent syscalls in a single PR?

@Xyene
Xyene force-pushed the allow-landlock branch 2 times, most recently from 84232d3 to 52c3315 Compare January 31, 2022 13:40
@Xyene

Xyene commented Jan 31, 2022

Copy link
Copy Markdown
Contributor Author

Whoops, forgot that they're not multiplexed from one syscall.

Allowing more recent syscalls sounds good to me; I just didn't want to rock the boat too much in this PR.

@Xyene Xyene changed the title seccomp: add support for "landlock" syscall in default policy seccomp: add support for Landlock syscalls in default policy Jan 31, 2022
This commit allows the Landlock[0] system calls in the default seccomp
policy.

Landlock was introduced in kernel 5.13, to fill the gap that inspecting
filepaths passed as arguments to filesystem system calls is not really
possible with pure `seccomp` (unless involving `ptrace`).

Allowing Landlock by default fits in with allowing `seccomp` for
containerized applications to voluntarily restrict their access rights
to files within the container.

[0]: https://www.kernel.org/doc/html/latest/userspace-api/landlock.html

Signed-off-by: Tudor Brindus <[email protected]>
@tianon

tianon commented Feb 7, 2022

Copy link
Copy Markdown
Member

We need to also verify there aren't any system calls in between these ones' numbers and what's already in the profile, right?
(For the ENOSYS vs EPERM workarounds/logic)

@tonistiigi
tonistiigi dismissed their stale review February 10, 2022 19:47

Issue resolved

@mwhudson

Copy link
Copy Markdown
Contributor

thanks @tianon for the ping. I adapted a script I'd written a while ago into this: https://gist.github.com/mwhudson/d28706022141a0cb631328c3a1adad50 (using this handy python packge: https://github.com/hrw/python-syscalls).

Running it on this PR produced this output:

(master)mwhudson@anduril:~/src/upstream/moby$ PYTHONPATH=~/src/upstream/python-syscalls/ python3 ~/tmp/diff-seccomp-profiles.py master allow-landlock
REMOVED from the implicit ENOSYS set:
 ['landlock_add_rule', 'landlock_create_ruleset', 'landlock_restrict_self', 'mount_setattr', 'quotactl_fd']
ADDED to the implicit EPERM set:
 ['mount_setattr', 'quotactl_fd']

The removal of the landlock_* syscalls from the ENOSYS set is the point. Someone should thing about the mount_setattr and quotactl_fd changes though!

(I think it would be awesome if someone could wrap up this script as a github action that posted to all PRs touching profiles/seccomp/default.json! I don't really know how to do that though)

@thaJeztah

Copy link
Copy Markdown
Member

I think it would be awesome if someone could wrap up this script as a github action that posted to all PRs touching profiles/seccomp/default.json! I don't really know how to do that though

Calling my go-to buddy for everything GitHub actions @crazy-max

@thaJeztah thaJeztah added this to the 21.xx milestone Mar 16, 2022
@thaJeztah

Copy link
Copy Markdown
Member

Looks like we have approval on the seccomp changes itself; we can looks at automating the check separately 👍

@thaJeztah thaJeztah left a comment

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

7 participants