Messages in this thread | | | Date | Mon, 16 Mar 2009 12:05:20 -0500 | From | "Serge E. Hallyn" <> | Subject | Re: VFS, NFS security bug? Should CAP_MKNOD and CAP_LINUX_IMMUTABLE be added to CAP_FS_MASK? |
| |
Quoting J. Bruce Fields (bfields@fieldses.org): > On Mon, Mar 16, 2009 at 12:36:11PM -0400, bfields wrote: > > That may be reasonable, but I'd like to see clearer criteria for > > choosing those. Some considerations: > > > > 1. As capabilities(7) says, we must "preserve the traditional > > semantics for transitions between 0 and non-zero user IDs". > > The setfsuid() interface predates capabilities, so the > > introduction of capabilities shouldn't have changed the > > behavior of a program written in ignorance of capabilities. > > 2. Users of the interface (like nfsd!) would be less likely to > > make mistakes if we had a simpler, more conceptual > > description of CAP_FS_MASK than just "the following list of > > capabilities". > > 3. If there's a possibility new capabilities will be added again > > in the future, then we should document CAP_FS_MASK in a way > > that makes it clear how those new bits will be treated. > > 4. We must fix nfsd in any case, either by changing the nfsd > > code or CAP_FS_MASK, but we should err on the side of not > > changing CAP_FS_MASK, for obvious backwards-compatibility > > reasons. > > Also, thinking of the nfsd case: it violates the principal of least > surprise if dropping CAP_FS_MASK still leaves it possible to make a > change to the filesystem that would normally require special > privileges....
Agreed, and so between that and the labeled nfs work, I think we should add all 4 capabilities to both the CAP_FS_MASK and CAP_NFSD_MASK.
-serge
| |