linux-kernel - Re: AppArmor FAQ

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 17 Apr 2007 23:16:53 +0200
From:	Andi Kleen <andi@...stfloor.org>
To:	Casey Schaufler <casey@...aufler-ca.com>
Cc:	Andi Kleen <andi@...stfloor.org>, James Morris <jmorris@...ei.org>,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: AppArmor FAQ

> For SELinux to be effective it has to have a complete policy definition.
> This would prevent the OpenOffice access (unless OpenOffice is in the
> modify_resolv_conf_t domain) above.

This would mean no fully functional root user anymore. My understanding 
is rather that at least in the Fedora default setup individual applications
are confined with targetted policy and root left alone because normal system 
administrators get very unhappy when root becomes powerless.

I was merely pointing out that in this setup path or namespace based access 
control are much easier to fit in than label based access because they normally 
don't require changing applications. John's original document also
listed some other advantages that I don't need to repeat.

In "i don't care if it looks like Unix anymore" security setups like
you're describing that's undoubtedly different and labels might indeed
work because you forbid just anybody changing them easily. If that makes
the users happy is a different question though. I suppose it will
keep security consultants employed at least @)

Arguably the preserving label issue is not unique to SELinux but 
also applies to ACLs and other possible uses of EAs, but then people normally 
don't need to set any ACLs on /etc/resolv.conf.

I personally don't like either too much. Path based access control
is somewhat hackish and ugly and slow in the current implementation, 
but I haven't seen an similarly easy to configure solution yet.

plan9 like limited namespaces for individual processes initially seem 
like a nice alternative, but in practice they're also too hard to use and 
suffer from many of the problems the EA label approach has.

But easy to use security is probably better than complicated security
because normal people will more likely use it.

-Andi

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/