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: <200705242356.29370.agruen@suse.de>
Date:	Thu, 24 May 2007 23:56:28 +0200
From:	Andreas Gruenbacher <agruen@...e.de>
To:	Al Viro <viro@....linux.org.uk>
Cc:	James Morris <jmorris@...ei.org>, jjohansen@...e.de,
	linux-kernel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, chrisw@...s-sol.org,
	Tony Jones <tonyj@...e.de>
Subject: Re: [AppArmor 01/41] Pass struct vfsmount to the inode_create LSM hook

On Thursday 24 May 2007 20:40, Al Viro wrote:
> On Thu, May 24, 2007 at 08:10:00PM +0200, Andreas Gruenbacher wrote:
> 
> > Read it like this: we don't have a good idea how to support multiple 
> > namespaces so far. Currently, we interpret all pathnames relative to the 
> > namespace a process is in. Confined processes don't have the privilege to 
> > create or manipulate namespaces, which makes this safe. We may find a
> > better future solution.
> 
> You also don't have a solution for multiple chroot jails, since they
> often have the same fs mounted in many places on given box *and* since
> the pathnames from the confined processes' POVs have fsck-all to do
> with each other.
>
> It's really not kinder than multiple namespaces as far as your approach
> is concerned.

Well, the pathnames we check against are namespace relative, so no matter what 
pathnames the chrooted processes think they are looking at, we always know 
the actual pathnames up to ``outside the chroot''. Having the same filesystem 
mounted in multiple chroots or in multiple locations in the same chroot 
doesn't matter.

The main problem I see when it comes to defining per-namespace policy is that 
namespaces are inherently anonymous, and there is no obvious way of 
associating different sets of profiles with different namespaces. 
Implementing something to also handle multiple namespaces doesn't seem 
hard -- after all, it's not such a difficult concept -- but I don't have a 
good enough idea what would work best.

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/