9 ms·
Landlock merged in mainline for Linux 5.13
- sneak 5y agoThis is cool, and lays the groundwork for per-directory, per-app access controls like on current macOS. Is there a comparable thing for network access? Last I looked OpenSnitch seemed to be unmaintained, but looking just now it apparently has some commits on master recently again: https://github.com/evilsocket/opensnitch https://github.com/evilsocket/opensnitch
- gruez 5y agoCan't you already do that? Just run every app in its own container, and firewall each container individually (since they can each have their own networking stack).
- bb88 5y agoSure, but why would I want to run 'ls' in it's own container?
- yjftsjthsd-h 5y agoBecause you want to prevent it from using network? You don't need a full "container", just a network namespace, but it's the same tech.
- hawski 5y agoI agree. Containers in the core are really two things, the latter is optional: unshare and cgroups.
- gruez 5y agocontainer is the only way for this to be airtight. Otherwise your malicious script can just call out to wget/curl (which is probably whitelisted) to bypass your firewall.
- nfoz 5y agoI'm not sure of all the history, but it feels to me like there were two cute ideas of the classic shell metaphor that we never quite achieved, and anyway we've totally outgrown: 1. That the shell's user is "in" a location of the filesystem (cwd), and can move around it like you're an avatar navigating rooms. 2. That the shell can "only" do program invocation, such that even its basic primitives like 'cd' and '[' can be just themselves programs. It's heretical, but, I don't think ls ought to be its own program. It's part of the shell, in particular part of my view of the filesystem. It's not really an app and I don't care if it happens to be implemented that way under the hood. As a user, I want a shell that lets me navigate the system (possibly multiple sets of systems), with a consistent set of primitives. It can let me invoke applications, and I want an absolute and extremely tight set of controls over those applications, and very specific ways that they're allowed to talk to each other. I'm running far off-topic but to your original point, I think "ls" isn't really the type of app we ought to be talking about here, just bake it into the shell...... ok I just want to abandon posix and work in new metaphors. That really is off-topic for discussions about a new Linux feature I guess.
- chungy 5y ago> 2. That the shell can "only" do program invocation, such that even its basic primitives like 'cd' and '[' can be just themselves programs. "cd" is one of a few commands that basically must be built-ins no matter what, since it has to modify the environment of the shell itself. Any external command can only modify its own environment, not the shell's environment.
- zerocrates 5y agoJust have cd spawn you a new shell that's in a new working directory, solved! Call it the immutable shell.
- HideousKojima 5y agoHave it contain a hash of the previous shell and cryptographically verify its authenticity with all of the electricity in Argentina and you can even get the crypto guys to promote it for you for free!
- deleted 5y ago[deleted]
- staticassertion 5y agoWell, why do you want to run 'ls' in a sandbox?
- fsflover 5y agoOr you can just use Qubes OS.
- heavyset_go 5y agoLinux has network namespaces for isolation and restriction, not sure if that's what you're looking for, though.
- touisteur 5y agoNamespaces + internal netns firewall + seccomp might do the trick :-)
- quaintdev 5y agoFirejail - https://github.com/netblue30/firejail https://github.com/netblue30/firejail
- megous 5y agoI use skuid based firewall rules + locked down permissions on the host so that processes can't elevate their privileges/change the user. Works fine enough for untrusted non-gui SW, and trusted GUI SW, that I know will not try to hack my PC, but apps running inside it may be able to access stuff I don't want them to on my network (like Firefox). cgroups may also work well for this without the need to use multiple UNIX users.
- n3mes1s 5y agoThere is a sort of opensnitch based on ebpf but not sure is fully feature completed as you intended: https://github.com/harporoeder/ebpfsnitch https://github.com/harporoeder/ebpfsnitch
- zie 5y agoPledge is like 100% easier to understand. FreeBSD has similar stuff and it is also super complicated and basically unused.. If you can't make this idiot proof, there is little hope anyone will ever use it.
- V-eHGsd_ 5y ago"make something idiot proof, and then they come along and invent a better idiot"
- wahern 5y agoReading the documentation my guess is that landlock works similar to OpenBSD unveil, where the kernel pins and tags a dentry object. If a path walk doesn't traverse a tagged dentry object w/ an allow flag, or the most recently traversed dentry has a block flag, the open fails. That neatly avoids the need to compare paths. One caveat is that renames, particularly renames of directories, might not behave as expected from the perspective of a user specifying paths. Linux thread semantics wrt credentials are likely to be an achilles heel, though, from an exploit mitigation perspective. Also, the fact that all subprocesses inherit these restrictions means it becomes very difficult to refactor tools to use minimal permissions when those tools need to invoke other tools. This is a lesson that OpenBSD learned the hard way, has explained very clearly, and the fact it has fallen on deaf ears is disconcerting. This is one reason for the lack of seccomp uptake, and landlock is recapitulating the same mistake.
- comex 5y ago> Also, the fact that all subprocesses inherit these restrictions means it becomes very difficult to refactor tools to use minimal permissions when those tools need to invoke other tools. This is a lesson that OpenBSD learned the hard way, has explained very clearly, and the fact it has fallen on deaf ears is disconcerting. If subprocesses don’t inherit sandbox restrictions, can’t you trivially escape the sandbox by spawning a subprocess to do whatever work you want? What exactly are you proposing here?
- wahern 5y ago
- 0xbadcafebee 5y agoCan someone explain the use case for this? If you control the system, you can use SELinux etc to control the same things. In what cases are you running an app on a system, and you don't control the system, and you don't want a user to access parts of the system? If it's about preventing system compromise, it's better to secure the whole system than one application...
- boustrophedon 5y agoI believe the usecase is similar to BSD's pledge. See https://man.openbsd.org/pledge.2 https://man.openbsd.org/pledge.2 It allows you to drop privileges so that in the event there is a vulnerability in your application, it cannot be exploited to cause further damage outside the scope of the application's normal operations.
- wahern 5y agoNot pledge, but unveil: https://man.openbsd.org/unveil.2 https://man.openbsd.org/unveil.2 AFAICT, landlock even uses the same underlying technique in the VFS layer.
- comex 5y agoI think the point is that applications can sandbox (parts of) themselves in a way that works across distros and doesn’t require a specific system configuration. Think of BSD pledge(), or browser sandboxes. (Browser sandboxes currently use seccomp on Linux. seccomp is good for when you want to disallow almost all syscalls, which browser sandboxes can do due to their highly elaborate design, including routing all file and network access through another process. It’s not so good for when you would like to keep interacting with the kernel directly but just want to limit accessible file paths.)
- 0xbadcafebee 5y agoI guess what I'm wondering is, are there cases where there's no other option except a sandbox? I get that you basically are shipping apps to random computers that aren't secure, so this is sort of a big band-aid for apps that can't tightly control for how their apps are used. But in terms of merging something into the kernel, wouldn't the kernel devs prefer to improve adoption of least-privilege/MAC LSMs?
- KingOfCoders 5y agoWhen I read "restrict themselves" I think of OpenBSD, is this the same?
- PostThisTooFast 5y agoMEANINGLESS TITLE ALERT
- deleted 5y ago[deleted]
- littlestymaar 5y agoI'm completely lost with Linux sandboxing and security tools , AFAIK there is - cgroups - cgroupsV2 - namespaces - AppArmor - SELinux - LSM - seccomp - seccomp-bpf - eBPF (I know it's not a security thing per se, but it's a building block for sandboxes) - and now landlock. Could anyone here give me an ELI5 about which one does what? (also which one you're supposed to use together, and which are competitors to each others) Or maybe give me some pointer to a good introduction to these?
- LucidLynx 5y agoYou forgot firejail also... I am completely lost too, and have the feeling that anyone has pros / cons, and no one is really an efficient product to be used in the daily life :/ I used firejail many months and got several issues with maintaining configurations for different softwares, especially after software updates. Also, those are softwares on top of the kernel I think, and not utilities in the kernel directly, but I may be wrong for this.
- littlestymaar 5y agoI didn't mention Firejail because it's actually build on top of seccomp-bpf and namespaces. It's a user-space application, leveraging existing kernel features, but unless I'm even more confused than I thought (which wouldn't surprise me, tbh), the others I mentioned live in the kernel (though AFAIK AppArmor and SELinux are security module running in kernel space but not part of the kernel itself).
- wyldfire 5y agoThe slides [1] help distinguish landlock from the others, IMO. Landlock uniquely has: the fine grained controls similar to SELinux, embedded policy (not up to the admin whether to deploy the security measure), and unprivileged use. [1] https://landlock.io/talks/2019-09-12_landlock-summary.pdf https://landlock.io/talks/2019-09-12_landlock-summary.pdf
- staticassertion 5y ago> - AppArmor > - SELinux > - LSM Let's group these three up. LSM is how Apparmor and SELinux are implemented. LSMs were the de-facto way to accomplish mandatory or role based access control on Linux, as opposed to the default user/group "discretionary" access control (DAC). SELinux was developed for building very very powerful policies, often to its detriment as it was not unusual for policies to be flawed due to that complexity. These days though I think it's doing pretty well on Android. Apparmor is much simpler, though less powerful. It leverages a per-process sandboxing model, mostly focusing on read/write/execute permissions for the filesystem for a given process. > - seccomp > - seccomp-bpf The OG seccomp gave a program access to four system calls. 'exit', 'sigreturn', 'read', and 'write'. Basically if you had, say, a parser, you could fork and exec it within a seccomp sandbox. All it could do is read/write to the inherited pipes - so, it could read stdin, write to stdout. Really cool, but limited. seccomp-ebpf was an extension of the idea behind seccomp - that is, policies on system calls. The main idea is that system calls are the way that shit gets done, whether it's exploiting the kernel or actually just performing malicious actions. So, we want to limit them. This works by pushing policies up to the ebpf kernel virtual machine, and that thing makes decisions about what to allow or not. It's very powerful and effective, but it's hard to maintain because you have to know your syscalls ahead of time. > - cgroups > - cgroupsV2 cgroups are less about sandboxing and more about restricting resource usage. > - namespaces Namespaces give a program its own view of some slice of your system. In a pid namespace it won't see other processes, unless they're in that same namespace. In a network namespace the process will think it's got its own network to itself. This is obviously quite useful for containers. There's even more than that though, way more. There's Yama, another LSM. There's chroots, chroot jails. There's the entire DAC system with users and groups. Root "capabilities". Windows isn't a ton better fwiw, it has jobs, integrity (including undocumented hidden integrity levels), virtual desktops, DAC, AppContainer (or something?), AppLocker, UAC virtualization, etc. In terms of what to use, that depends. Apparmor and SELinux are distro-specific, but IMO Apparmor is pretty trivial to write and maintain so it's sort of a harmless thing to deliver alongside a service/application. Seccomp is arguably the most powerful, I think in particular if it's combined with namespaces (since you can't do things like filter on pointer arguments to system calls, so filtering on file path etc is out) this is really damn powerful, assuming a tight seccomp filter. But you'll want really good test coverage so that you can determine ahead of time if you accidentally introduced a new system call. The main thing imo is to take the dangerous part of your program and isolate it into a small component. That's just the most important thing to do, and from there sandboxing becomes (more or less) trivial. That component can run as an unprivileged user, or in a namespace with no access, or in a seccompv1 jail with nothing but a pipe for reading/ and writing.