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]

Date:	Fri, 25 May 2007 06:14:08 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	casey@...aufler-ca.com
Cc:	James Morris <jmorris@...ei.org>, linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On Thursday 24 May 2007 20:58, Casey Schaufler wrote:
> On Fedora zcat, gzip and gunzip are all links to the same file.
> I can imagine (although it is a bit of a stretch) allowing a set
> of users access to gunzip but not gzip (or the other way around).
> There are probably more sophisticated programs that have different
> behavior based on the name they're invoked by that would provide
> a more compelling arguement, assuming of course that you buy into
> the behavior-based-on-name scheme. What I think I'm suggesting is
> that AppArmor might be useful in addressing the fact that a file
> with multiple hard links is necessarily constrained to have the
> same access control on each of those names. That assumes one
> believes that such behavior is flawwed, and I'm not going to try
> to argue that. The question was about an example, and there is one.

Different policy for different names of the same binary makes more obvious 
sense with chroot environments. That's slightly different from having 
different permissions for the same file within a single profile though.

Thanks,
Andreas
-
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/