Re: (repost) Confirmation of methods for calculating requestedpathname.

[Stephen Smalley]

On Tue, 2008-09-02 at 08:11 -0500, Serge E. Hallyn wrote:
> Quoting Kentaro Takeda (takedakn@xxxxxxxxxxxxx):
> > 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/