Landlock supervise: a mechanism for interactive permission requests
Hi,
I would like to propose an extension to Landlock to support a "supervisor"
mode, which would enable a user program to sandbox applications (or
itself) in a dynamic, fine-grained, and potentially temporary way.
Practically, this makes it easy to give maximal control to the user,
perhaps in the form of a "just in time" permission prompt. Read on, or
check the sandboxer program in the last patch for a "demo".
To Jan Kara and other fanotify reviewers, I've included you in this patch
as Mickaël suggested that we could potentially extend and re-use the
fanotify uapi and code instead of creating an entirely new representation
for permission requests and mechanism for passing it (as this patch
currently does). I've not really thought out how that would work (there
will probably have to be some extension of the fanotify-fd uapi since
landlock handles more than FS access), but I think it is a promising idea,
hence I would like to hear your thoughts if you could spare a moment to
look at this. A good outcome could also be that we add the necessary
hooks so that both this and fanotify (but really fsnotify?) can have _perm
events for create/delete/rename etc.
FS mailing list - I've CC'd this patchset to you too - even though the
patch doesn't currently touch any FS code, this is very FS related, and
also, in order to address an inode lock related problem which I will
mention in patch 6 of this series, future versions of this patch will
likely need to add a few more LSM hooks. Especially for that part, but
also other bits of this project, a pair of eyes from the FS community
would be very helpful.
To Tycho Andersen -- I'm CC'ing you as you've worked on the seccomp-unotify
feature which is also quite related, so if you could spare some time for a
quick review, or provide some suggestions, that would be very appreciated
:)
I'm submitting this series as a non-production-ready, proof-of-concept
RFC, and I would appreciate feedback on any aspects of the design or
implementation. Note that due to the PoC nature of this, I have not
handled checkpatch.pl errors etc. I also welcome suggestions for
alternative names for this feature (e.g. landlock-unotify?
landlock-perm?). At this point I'm very keen to hear some initial
feedback from the community before investing further into polishing this
patch.
(I've briefly pitched the overall idea to Mickaël, but he has not reviewed
the patch yet)
Why extend landlock?
--------------------
While this feature could be implemented as its own LSM, I feel like it is
a natural extension to landlock -- landlock has already defined a set of
fine-grained access requests with the intention to add more (and not just
for FS alone), is designed to be an unprivileged, stackable,
process-scoped, ad-hoc mechanism with no persistent state, which works
well as a generic API to support a dynamic sandbox, and landlock is
already doing the path traversal work to evaluate hierarchical filesystem
rules, which would also be useful for a performant dynamic sandbox
implementation.
Use cases
---------
I have several potential use cases in mind that will benefit from
landlock-supervise, for example:
1. A patch to firejail (I have not discussed with the firejail maintainers
on this yet - wanted to see the reception of this kernel patch first)
which can leverage landlock in a highly flexible way, prompting the user
for permission to access "extra" files after the sandbox has started
(without e.g. having to restart a very stateful GUI program).
This way of using landlock can potentially replace its current approach of
using bind mounts (as it will allow implementing "blacklists"), allowing
unprivileged sandbox creation (although need to check with firejail if
there are other factors preventing this). This also allows editing
profiles "live" in a highly interactive way (i.e. the user can choose
"allow and remember" on a permission request which will also add the newly
allowed path to a local firejail profile, all automatically)
2. A "protected" mode for common development environments (e.g. VSCode or
a terminal can be launched "protected") that doesn't compromise on
ease-of-use. File access to $PWD at launch can be allowed, and access to
other places can be allowed ad-hoc by the developer with hopefully one UI
click. Since landlock can also be used to restrict network access, such a
protected mode can also restrict outgoing connections by default (but ask
the user if they allow it for all or certain processes, on the first
attempt to connect).
Recently there has been incidents of secret-stealing malware targeting
developers (on Linux) by social engineering them to open and build/run a
project. [1] The hope is that landlock-supervise can drive adoption of
sandboxes for developers and others by making them more user-friendly.
In addition to the above, I also hope that this would help with landlock
adoption even in non-interaction-heavy scenarios, by allowing application
developers the choice to gracefully recover from over-restrictive rulesets
and collect failure metrics, until they are confident that actually
blocking non-allowed accesses would not break their application or degrade
the user experience.
I have more exploration to do regarding applying this to applications, but
I do have a working proof of concept already (implemented as an
enhancement to the sandboxer example). Here is a shortened output:
bash # env LL_FS_RO=/usr:/lib:/bin:/etc:/dev:/proc LL_FS_RW= LL_SUPERVISE=1 ./sandboxer bash -i
bash # echo "Hi, $(whoami)!"
Hi, root!
bash # ls /
------------- Sandboxer access request -------------
Process ls[166] (/usr/bin/ls) wants to read
/
(y)es/(a)lways/(n)o > y
----------------------------------------------------
bin
boot
dev
...
usr
var
bash # echo 'evil' >> /etc/profile
(a spurious create request due to current issue with dcache miss is omitted)
------------- Sandboxer access request -------------
Process bash[163] (/usr/bin/bash) wants to read/write
/etc/profile
(y)es/(a)lways/(n)o > n
----------------------------------------------------
bash: /etc/profile: Permission denied
bash #
Alternatives
------------
I have looked for existing ways to implement the proposed use cases (at
least for FS access), and three main approaches stand out to me:
1. Fanotify: there is already FAM_OPEN_PERM which waits for an allow/deny
response from a fanotify listener. However, it does not currently have
the equivalent _PERM for file creation, deletion, rename and linking, and
it is also not designed for unprivileged, process-scoped use (unlike
landlock).
2. Seccomp-unotify: this can be used to trap all syscalls and give the
sandbox a chance to allow or deny any one of them. However, a correct,
TOCTOU-proof implementation will likely require handling a large number of
fs-related syscalls in user-space, with the sandboxer opening the file or
carrying out the operation on behalf of the sandboxee. This is probably
going to be extremely complex and makes everything less performant.
3. Using a FUSE filesystem which gates access. This is actually an
approach taken by an existing sandbox solution - flatpak [2], however it
requires either tight integration with the application (and thus doesn't
work well for the mentioned use cases), or if one wants to sandbox a
program "transparently", SYS_ADMIN to chroot.
I've tested that what I have here works with the enhanced sandboxer, but
have yet to write any self tests or do extensive testing or perf
measurements. I have also yet to implement support for supervising tcp
rules as well as FS refer operations.
Base commit: 78332fdb956f18accfbca5993b10c5ed69f00a2c (tag:
landlock-6.14-rc5, mic/next)
[1]: https://cybersecuritynews.com/beware-of-lazarus-linkedin-recruiting-scam/
[2]: https://flatpak.github.io/xdg-desktop-portal/docs/documents-and-fuse.html
Tingmao Wang (9):
Define the supervisor and event structure
Refactor per-layer information in rulesets and rules
Adds a supervisor reference in the per-layer information
User-space API for creating a supervisor-fd
Define user structure for events and responses.
Creating supervisor events for filesystem operations
Implement fdinfo for ruleset and supervisor fd
Implement fops for supervisor-fd
Enhance the sandboxer example to support landlock-supervise
include/uapi/linux/landlock.h | 119 ++++++
samples/landlock/sandboxer.c | 759 +++++++++++++++++++++++++++++++++-
security/landlock/Makefile | 2 +-
security/landlock/fs.c | 134 +++++-
security/landlock/ruleset.c | 49 ++-
security/landlock/ruleset.h | 66 +--
security/landlock/supervise.c | 194 +++++++++
security/landlock/supervise.h | 171 ++++++++
security/landlock/syscalls.c | 621 +++++++++++++++++++++++++++-
9 files changed, 2036 insertions(+), 79 deletions(-)
create mode 100644 security/landlock/supervise.c
create mode 100644 security/landlock/supervise.h
--
2.39.5
