[RFC PATCH 0/9] Landlock supervise: a mechanism for interactive permission requests
Tingmao Wang
m at maowtm.org
Mon Mar 24 01:58:21 UTC 2025
On 3/12/25 06:20, Tetsuo Handa wrote:
> On 2025/03/04 10:12, Tingmao Wang wrote:
>> 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 #
>
> Please check TOMOYO, for TOMOYO is already doing it.
>
> https://tomoyo.sourceforge.net/2.6/chapter-7.html#7.3
>
Hi Tetsuo,
Thanks for commenting on this RFC and thanks for mentioning TOMOYO - I
wasn't aware that another LSM has a similar permission prompting
mechanism already (and in fact, I only recently found out AppArmor /
Ubuntu has also built something like this [1], although AFAIK it's not
upstream'd to mainland Linux, and the current implementation may be
somewhat coupled with Snap?), and this is valuable and interesting for
me to know :)
I've tried out TOMOYO and it seems quite applicable to the
"firejail-like dynamic sandbox" use case (i.e. use cases #1 in the cover
letter) I initially wanted to enable, and so I would like to investigate
this further. If you don't mind, I would like to ask, have you built /
are you aware of any end-user-facing GUI for tomoyo-queryd? There is
one on GitHub by someone else [2], but I'm wondering if you have tried
to, or thought about building a UI that's a bit richer (e.g. like the
one in [1]).
I've looked into the TOMOYO query protocol and I was thinking that, if I
do end up building something for this purpose, it could perhaps support
TOMOYO as a "backend" (and in fact that would be usable with the current
feature in TOMOYO already, whereas a landlock-based one would depend on
this patch). But if you have already tried something like this I would
of course want to know beforehand :)
btw, maybe this is just me not looking hard enough, but is there a git
(or similar) repository for the user space programs (tomoyo-tools)? I
tried to search online but so far I only found source tarballs,
including the pages on sourceforge, and I'm wondering if there is a
place with latest development branches.
I want to perhaps submit some patches to the user-space tools (I assume
they should go to tomoyo-dev-en?) if that's welcome.
--
With that said, I should clarify that I think this supervisor feature is
still valuable for landlock even knowing the existing TOMOYO query
feature. The intention is not to duplicate what TOMOYO already does, but
to offer flexibility for landlock users and feature parity (with TOMOYO
and things like seccomp-unotify), and allows program sandboxing
themselves (or other children) with landlock more flexibility. The
second use case mentioned in the cover letter would benefit from this
(and a user-level / system-wide sandbox program can also choose to
leverage this, potentially running unprivileged etc). I will try and
prototype a more interesting example to validate the practicality (most
importantly UX) and use in the cover letter for the next series. (Will
also rename the series title to just "Landlock supervise" to avoid
sounding like interactive permission requests are a new thing)
Kind regards,
Tingmao
[1]:
https://discourse.ubuntu.com/t/ubuntu-desktop-s-24-10-dev-cycle-part-5-introducing-permissions-prompting/47963
[2]: https://github.com/Intika-Linux-Firewall/Tomoyo-Application-Firewall
More information about the Linux-security-module-archive
mailing list