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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 24 May 2007 09:19:35 -0400 (EDT)
From:	James Morris <jmorris@...ei.org>
To:	Andreas Gruenbacher <agruen@...e.de>
cc:	Al Viro <viro@....linux.org.uk>, 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 Thu, 24 May 2007, Andreas Gruenbacher wrote:

> > Would you mind providing some concrete examples of how such a model would
> > be useful?
> 
> The model is explained, with examples, in the technical documentation at http://forgeftp.novell.com//apparmor/LKML_Submission-May_07/.

I'm asking specifically about a model where you'd want to provide 
differing access to the same objects based on the pathname used for 
access to the objects, per:

  "If files are mounted at multiple locations, then the policy may allow 
   access to some locations but not to others.  That's not a hole."

I don't see specific examples of this kind of policy in that document, 
and the document seems to be saying quite the opposite -- that the AA 
policy is only valid in conjunction with further constraints on how the 
objects may be accessed:

Section 3.2:

 "Pathnames are meaningful only within a namespace. Each namespace has a 
  root where all the files, directories, and mount points are hanging off 
  from.

  The privilege of creating new namespaces is bound to the CAP_ SYS_ ADMIN 
  capability, which grants a multitude of other things that would allow a 
  process to break out of AppArmor confinement, so confined processes are 
  not supposed to have this privilege, and processes with this capability 
  need to be considered trusted. "

I can restate my question and ask why you'd want a security policy like:

  Subject 'sysadmin' has:
     read access to /etc/shadow
     read/write access to /views/sysadmin/etc/shadow

where the objects referenced by the paths are identical and visible to the 
subject along both paths, in keeping with your description of "policy may 
allow access to some locations but not to others" ?

- James
-- 
James Morris
<jmorris@...ei.org>
-
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/