linux-kernel - Re: [AppArmor 01/41] Pass struct vfsmount to the inode

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]

Message-ID: <465D0ED5.3070305@novell.com>
Date:	Wed, 30 May 2007 01:42:45 -0400
From:	Crispin Cowan <crispin@...ell.com>
To:	Pavel Machek <pavel@....cz>
CC:	Cliffe <cliffe@...et.net.au>, casey@...aufler-ca.com,
	Kyle Moffett <mrmacman_g4@....com>,
	linux-security-module <linux-security-module@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM
 hook

Pavel Machek wrote:
>>     * Hard links: AppArmor explicitly mediates permission to make a hard
>>     
> Unfortunately, aparmor is by design limited to subset of distro
> (network daemons).
That is not true. AppArmor is designed to confine any application you do
not want to trust completely. This includes network daemons (Apache,
Sendmail, BIND, etc.) network clients (Firefox, Thunderbird,
GAIM/Pidgin, etc.) and any other application that mediates trust: where
data on one side of the application is higher privilege than potential
attackers on the other side of the application.

>  Unfortunately, some other programs (passwd, vi)
> routinely make hardlinks. So AA mediating hardlink is not enough, as
> vi will happily hardlink /etc/shadow into /etc/.vi-shadow-1234.
>   
I have no idea what you are talking about. I routinely profile vim on
stage in AppArmor presentations, and it presents no such problems.

Caveat: the circumstances under which you would actually want to profile
vi are rather limited, most users would not want to do that.

In another post Pavel Machek wrote:
> Hmm, I guess I'd love "it is useless on multiuser boxes" to become
> standard part of AA advertising.
That is usually around slide 7 of the standard AppArmor presentation,
right next to the remarks about how mulituser boxes are nearly extinct
dinosaurs. AppArmor gets some of its simplicity and ease of use by not
considering that vanishing use case. Even so, AppArmor does have uses on
multiuser boxes, just not the uses Pavel wishes for. Fine, use a
different tool for a different task, AppArmor has plenty of use cases.

The limitation Pavel is referring to is that AppArmor does not secure
processes that are not profiled by AppArmor. We know, this is
intentional, and contributes to AppArmor's ease of use, and does not
generate a hole if you consider every process exposed to (say) network
attack and confine it.

Crispin

-- 
Crispin Cowan, Ph.D.               http://crispincowan.com/~crispin/
Director of Software Engineering   http://novell.com
		   Security: It's not linear

-
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/