Arch Linux

If Tomoyo depends on audit being compiled in, it's not going to be re-enabled. Audit is always enabled if it's compiled in, and this was the largest incentive to disable AppArmor, etc. If it's not required, then enabling it seems reasonable.

> Also, from a security point of view I'm worried, that now all LSMs are disabled, when these are one of the few (and probably the most usable) mechanisms to keep one skilled browser exploit from wreaking havoc in the whole system.

An LSM can not provide much protection against a browser exploit. A browser without built-in sandboxing will allow stealing all of the cookies (including session cookies), stored passwords, local storage / IndexedDB data, hijacking any active connections and substituting downloads with other files.

You'll get much farther by using a browser with sandboxing support like Chromium. It places every site instance into an empty chroot (no filesystem access), process namespace (no signals/ptrace/queries of other processes) and network namespace (no networking). It then whitelists only a few system calls via seccomp-bpf to cut down the kernel surface area to a minimum, because kernel exploits are quite common.

> Does tomoyo require audit to be enabled?

According to the documentation at http://akari.sourceforge.jp/comparison.html.en CONFIG_AUDIT seems not to be required. For TOMOYO, CONFIG_SECURITY_TOMOYO is missing from the current configuration, as well as CONFIG_SECURITY_NETWORK, but everything else is fine. Starting the kernel build process with only these two options added seems to work.

> An LSM can not provide much protection against a browser exploit.

That always depends on what you assume your attacker can do and what you want to protect against. In my case, I like Firefox better than Chromium, so I can't use its advanced sandboxing features. But I can use TOMOYO for example to forbid my Firefox to write to any directory other than Downloads, so that an attacker can never (without finding another kernel vulnerability) delete all my files, except for the temporary stuff in this one directory. Or I can use TOMOYO to ensure my Tor Browser Bundle only connects to its own Tor process, but cannot make any other network connections that might leak information.

> In my case, I like Firefox better than Chromium, so I can't use its advanced sandboxing features.

Sure, I'm just countering your statement about this being one of the best ways to secure a browser. It's quite a bit less secure than the Chromium sandbox since the browser as a whole is vulnerable and the kernel is very vulnerable to further exploitation. Most people use web mail clients, so a browser exploit is quite catastrophic with or without an external sandbox. I stayed with Firefox for a long time because I like Vimperator more than Vimium, but as a security conscious user I could not keep using a browser without even basic sandboxing.

> But I can use TOMOYO for example to forbid my Firefox to write to any directory other than Downloads, so that an attacker can never (without finding another kernel vulnerability) delete all my files, except for the temporary stuff in this one directory.

This can also be done with a mount namespace and bind mount too. There's initial support for doing this very easily with systemd (ReadWriteDirectories, ReadOnlyDirectories, InaccessibleDirectories). A MAC can do a lot more since it's not restricted to directories, but simple use cases can be covered without one.

> Or I can use TOMOYO to ensure my Tor Browser Bundle only connects to its own Tor process, but cannot make any other network connections that might leak information.

A network namespace can accomplish this, although we currently lack the tooling to do it without being intimately familiar with these features.

Since this does not require audit, I'm personally okay with re-enabling it *for now*. However, if `ptrace_scope` becomes available in the vanilla kernel I think LSM support should be disabled. I would be against enabling Tomoyo if it would be considered a blocker for removing LSM support as a whole in the future.

https://www.usenix.org/legacy/event/sec02/full_papers/wright/wright_html/node22.html#subsec:selinuxbench

> Because LSM is compiled and enabled in the kernel, its symbols are exported. Thus, every rootkit and backdoor writer will have every hook he ever wanted in the kernel. This will allow for a new generation of sophisticated backdoors and rootkits that will be nearly impossible to detect.

https://grsecurity.net/lsm.php

The ptrace_scope feature that we have enabled by default is useful enough to offset this, but without it I don't think enabling LSM is justified.

> Sure, I'm just countering your statement about this being one of the best ways to secure a browser.

All I ever said was that this is one of the few ways to add additional security to your browser. There will always be more/better things you can do, sandboxing probably being one of them (Though, even if MAC is only second best after sandboxing, technically, it's still one of the best ways ;-)). Are there other security techniques, apart from sandboxing, that you can recommend?

In general, my assumption here is that I don't stand a chance against targeted attacks, whether I try to defend against them or not. But for the more common attacks against everybody with the default configuration, adding just a little extra barrier like TOMOYO might make all the difference. There have been exploits in the wild (though for other platforms) that probably would have worked on my system, but where TOMOYO would have prevented any harm.

> This can also be done with ...

I'm glad to learn that there are alternatives for what I try to achieve. Of course, being already familiar with TOMOYO and positively surprised with how easy it is to use (when compared with some other MAC solutions that I've learned about at university), I'd rather keep it than try to rebuild the same functionality using other tools. Do you also know a way to recreate TOMOYOs functionality to grant different privileges depending on how a process has been started? So for example my PDF viewer, when started by the browser, may do hardly more than display the PDF, but when I manually run the same program it is allowed to talk to the printer.

Could you explain a bit more what ptrace_scope does and how it interacts with LSM? I'm a bit confused by your statements "if `ptrace_scope` becomes available in the vanilla kernel I think LSM support should be disabled" and "The ptrace_scope feature that we have enabled by default [...] without it I don't think enabling LSM is justified". So we already have some form of the ptrace_scope feature and because of that using LSM is okay, but once (some other form of?) ptrace_scope is available in the vanilla kernel we shouldn't be using LSM anymore?

ptrace_scope is a feature provided by an LSM (Yama) and we have it enabled by default. It prevents processes from debugging other processes outside of their scope. Since an LSM can't be stacked on top of another, this functionality is lost when using an alternative LSM like SELinux.

I'm tempted to start maintaining grsecurity in [community]. It's an enormous improvement in terms of preventing kernel exploitation and includes an RBAC system with learning capabilities able to do the same kind of stuff as AppArmor/TOMOYO and more. It can implement policies for combinations of specific users/binaries, etc. I think it's a much better option than the mainline LSM stuff and it wouldn't involve any cost for people not interested in using it.

> Starting the kernel build process with only these two options added seems to work.

And once built, the kernel and TOMOYO work as expected. The whole difference in the config for 3.14.0-5-ARCH is:

6204c6204,6205
< # CONFIG_SECURITY_NETWORK is not set
---
> CONFIG_SECURITY_NETWORK=y
> # CONFIG_SECURITY_NETWORK_XFRM is not set
6208c6209,6214
< # CONFIG_SECURITY_TOMOYO is not set
---
> CONFIG_SECURITY_TOMOYO=y
> CONFIG_SECURITY_TOMOYO_MAX_ACCEPT_ENTRY=2048
> CONFIG_SECURITY_TOMOYO_MAX_AUDIT_LOG=1024
> # CONFIG_SECURITY_TOMOYO_OMIT_USERSPACE_LOADER is not set
> CONFIG_SECURITY_TOMOYO_POLICY_LOADER="/sbin/tomoyo-init"
> CONFIG_SECURITY_TOMOYO_ACTIVATION_TRIGGER="/sbin/init"
6212a6219
> # CONFIG_DEFAULT_SECURITY_TOMOYO is not set


> Since an LSM can't be stacked on top of another, this functionality is lost when using an alternative LSM like SELinux.

Is this really the case? It looks like CONFIG_SECURITY_YAMA_STACKED (which is used in the Arch kernel) enables support for this special case.

> AFAIK it also has a significant performance cost.

Benchmarks (e.g. http://www.phoronix.com/scan.php?page=article&item=fedora_15_selinux http://www.phoronix.com/scan.php?page=article&item=fedora_debug_selinux) show a performance penalty of about 10% with SELinux/Audit enabled, mostly affecting Apache and disk I/O, while other workloads remain virtually unaffected. With LSM support present but not enabled no measureable performance impact could be found (https://mailman.archlinux.org/pipermail/arch-general/2014-March/035704.html).

Ah, I wasn't aware that there was a special case for Yama. It looks like the generic stacking support is in the process of landing upstream anyway. Although this doesn't require setting CONFIG_AUDIT, I expect the fact that it needs to be compiled in rather than as a module will bump up against the same opinions that led to these being disabled. Sorry for playing devil's advocate here, I just want to raise the concerns that I know were raised on the mailing list before.

> I expect the fact that it needs to be compiled in rather than as a module will bump up against the same opinions that led to these being disabled.

Wasn't the main argument for disabling all those options that Arch provided no (userspace) support for them, so they couldn't be used effectively? At least in the case of TOMOYO this was incorrect, as the tomoyo-tools package was present in [community] and worked correctly. Or was this about some other meaning of "support", like providing default rule sets?

As long as it does not negatively affect all users who do not want to use it (and we can probably agree on that in this case), I don't see a problem with things being compiled in, as it provides everybody else with a nice out-of-the-box experience. While it is not hard work to recompile the kernel with some custom options, I still have to listen to my fan spinning fast for an hour; and I have to do that every time there is a new kernel, if I do not want to risk hitting some bug, that has already been fixed. So for other software it is no problem to use a custom package, e.g. from the AUR, but for such a central component like the kernel, having support in the default package would be really helpful.

I too would like to see TOMOYO enabled in the default kernel again. I compiled both linux-3.14.1-1 and linux-3.14-5 kernels and can confirm TOMOYO works using the re-enabled settings mentioned by webmeister. I also have not noticed any performance impact. I use TOMOYO to restrict both firefox and thunderbird's filesystem access. While I don't have the knowledge to engage in the in-depth technical discussion you have been having, there is a use case that hasn't been mentioned. I also use TOMOYO to monitor and/or limit an application's network access. I haven't found another user-friendly way to do that in linux. I appreciate Arch Linux and its developers. Thanks for reading my comments and for any consideration you can give to restoring TOMOYO to the default kernel.

FWIW, the grsecurity kernel / userspace tools are now provided in [community]. It includes an RBAC system with path-based policies along with support for controlling networking, capabilities, and some other things. There's a nice learning mode like TOMOYO. Unlike most other path-based MAC implementations, it resolves the paths provided in the policy to inodes immediately so hard links can't poke holes in the policy.

https://wiki.archlinux.org/index.php/Grsecurity

Thanks for providing the grsecurity packages. I played with it in a VM and wasn't picking it up as quickly as I did TOMOYO. I'll try again this coming weekend when I have more time.