On 28/02/2017 22:56, Jorge Lucangeli Obes wrote:
> That sounds interesting! Do you have code somewhere that we could play
> around with?
There is an example in samples/bpf/landlock1_{user,kern}.c and other
pieces of code in tools/testing/selftests/landlock/ .
You can checkout the current version from here:
https://github.com/landlock-lsm/linux/commits/landlock-v5
However, if you want to get a taste of the feature to check if a file is
beneath another, you'll need to take a look at the landlock-v4 branch.
The BPF helper was in an early stage and didn't properly handled mount
points, though, which I plan to do next.
> In my opinion, being able to have Minijail policies that can express
> restrictions on files names would be extremely useful.
Underneath, I don't plan/want to check files according to path names,
but to check their dentry hierarchy instead (closer to SELinux than
AppArmor approach). To express such a file hierarchy, the process open
the root file/directory and pass its file descriptor to the kernel.
Something like this (from the previous version):
https://github.com/landlock-lsm/linux/blob/landlock-v4/samples/landlock/sandbox.c#L98-L118
But we'll hopefully see that in a next patch series.
Mickaël
>
> Cheers,
> Jorge
>
> On Sun, Feb 26, 2017 at 8:51 AM, Mickaël Salaün <
m...@digikod.net
> <mailto:
m...@digikod.net>> wrote:
>
> Hi,
>
> You may be interested by Landlock [1]. It's an LSM proposal I'm working
> on to bring programmatic access control to Linux. The final goal is to
> allow unprivileged sandboxing.
>
> I know you'd like some way to do deep inspection of syscall arguments
> with seccomp-bpf (e.g. for file path), which was the approach taken with
> the first version of Landlock (named seccomp-object at the time). The
> current version is much more advanced and should be a nice base to
> enhance sandboxing tools such as Minijail. The current version of
> Landlock is an MVP and hence lacks of features, but I plan to bring them
> back (especially an eBPF map type and function to check if a file is
> part of a file hierarchy) once/if a framework base is accepted.
>
> I'd like to get some feedback from your team, whether it's about your
> use cases, the UAPI, the kernel code or the documentation. Feel free to
> drop an email to the LKML. :)
>
> Regards,
> Mickaël
>
>
> [1]
https://lwn.net/Articles/715203/ <
https://lwn.net/Articles/715203/>
> <
https://groups.google.com/a/chromium.org/d/msgid/minijail/6f12bace-5796-c8ac-55a3-15e05a45f4ed%40digikod.net>.
>
>