[arch-general] [arch-dev-public] Trimming down our default kernel configuration

[Daniel Micay]

On 28/03/14 02:36 PM, Genes Lists wrote:
> On 03/28/2014 09:12 AM, Daniel Micay wrote:
>>
> ...
>>
>> Security needs to be simple, predictable and well understood. It needs
>> to be provably correct and easily audited. SELinux is none of these
>> things. I don't really understand why a distribution striving for
>> simplicity would ever enable it.
> 
> I think the above is a tad misleading.
> 
> While we don't yet have user space tools - which was I believe a key, if
> not critical, point Thomas was making - selinux is very useful and adds
> a strong security layer.  The kernel code is well audited and well
> tested in real world too.  Just not by us Arch folks - at least today -
> without the user space and policy support in core.

Well I don't really think it's useful, There are much simpler
alternatives, like isolating services and applications in containers
(chroot, namespaces, seccomp-bpf) and using AppArmor + the protected
symlink/hardlink switches (on by default) to pick up the slack when
you're not willing to put in much work.

Simplicity is really important in this domain, because you need to be
able to audit a full policy, and that's very difficult when data is
spread out through the filesystem. A mistake in the metadata for a
single file can break the isolation.

I don't really believe SELinux has a purpose beyond satisfying overly
complex security policies created by bureaucracy. I can't see Arch ever
being used in these situations.

> I cannot speak for AppArmor, but I do recall when the big debate to
> include it in mainline or not was going on, that Linus was a big
> proponent of using both together. Hence, today both are there.

AppArmor was not incredibly useful before Yama came along with the
protected symlink/hardlink features (now part of the core kernel). It's
useful now, but I still think you're better off using containers in most
cases. As far as I know, Linus is no fan of LSM and has done everything
he can to keep this stuff out of the core kernel. There are cases where
I think this was a mistake, like the `ptrace_scope` option requiring the
stub Yama LSM.

> And, it's not only for servers but for laptops as well. In fact newer
> versions of Android phones/tablets  use selinux enabled in enforcing
> mode. So with the right user space policies (redhat has some good base
> configs here) selinux could be a strong add for Arch linux in the future
> - maybe.

Android is not exactly a shining example of a security. SELinux hasn't
really changed anything other than adding a buzzword. The shared sdcard
data can still be read/written by any application (no permissions or
attributes there at all), and nothing else really changed. It might add
some defence in depth, but they could have gotten this by leveraging
namespaces/chroots or AppArmor too.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: OpenPGP digital signature
URL: <http://mailman.archlinux.org/pipermail/arch-general/attachments/20140328/33e275f7/attachment.asc>