linux-kernel - Re: (repost) Confirmation of methods for calculating requested pathname.

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, 02 Sep 2008 09:37:20 -0400
From:	Stephen Smalley <sds@...ho.nsa.gov>
To:	"Serge E. Hallyn" <serge@...lyn.com>
Cc:	Kentaro Takeda <takedakn@...data.co.jp>, viro@...IV.linux.org.uk,
	linux-fsdevel@...r.kernel.org,
	linux-security-module@...r.kernel.org,
	linux-kernel@...r.kernel.org, miklos@...redi.hu, hch@...radead.org,
	akpm@...ux-foundation.org,
	Toshiharu Harada <haradats@...data.co.jp>
Subject: Re: (repost) Confirmation of methods for calculating requested
	pathname.


On Tue, 2008-09-02 at 08:11 -0500, Serge E. Hallyn wrote:
> Quoting Kentaro Takeda (takedakn@...data.co.jp):
> > Al, could you answer the following question?
> > 
> > 
> > The current Linux kernel is not designed to pass vfsmount parameter
> > that is crucial for pathname-based security including AppArmor and
> > TOMOYO Linux, to LSM. Though both projects have been proposing
> > patches to calculate pathname, none of them have been accepted as
> > you know.
> > 
> > To find the reason for NACK, we examined past proposals and the
> > threads. And we came to understand that you oppose accessing vfsmount
> > inside vfs helper functions. Is our understanding correct?
> > 
> > If our understanding is correct, we would like to propose a new
> > method that does not require modifications to vfs helper functions.
> > Attached patch is a trial of this method.
> > 
> > vfs helper functions are surrounded by mnt_want_write() and
> > mnt_drop_write() pairs which receive "struct vfsmount" parameter
> 
> I thought Al and others (Stephen?) had made it clear that the thing to do was
> add new lsm hooks there.  So whereas inode_permission takes only an inode and
> ends up calling security_inode_permission, you would add a
> security_path_permission() or somesuch before or after the call to
> inode_permission(), where as you've noted the path is available.  You're
> *close* to doing the right thing by having a helper who is called at the right
> place catch the vfsmount, but you refuse to send a patch doing exactly what
> has been suggested.

No, that idea seemingly died because both Al and Miklos thought it was
wrong to add new security hooks to the same code path (vs. moving the
existing ones to the callers), but I was opposed to moving the existing
hooks as they are presently exactly where SELinux needs them, and moving
them to the callers raises concerns both with ensuring invocation on all
code paths (possible, but an ongoing maintenance concern) and with
performing DAC checks first where possible (which I think is also a
concern for TOMOYO et al).  Miklos' vfs path API showed more promise but
was rejected.

-- 
Stephen Smalley
National Security Agency

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