[lkml]   [2011]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [RFC][PATCH 0/7] File descriptor labeling
    On 4/27/2011 4:27 PM, Tyler Hicks wrote:
    > On Wed Apr 27, 2011 at 01:19:55PM -0700, Casey Schaufler <> wrote:
    >> On 4/27/2011 5:34 AM, Roberto Sassu wrote:
    >>> File descriptor labeling issue
    >>> Actually SELinux and SMACK assign to file descriptors the same label of the
    >>> opening process and use it in LSM hooks security_file_permission(),
    >>> security_file_fcntl() and others to verify if the 'current' process has the
    >>> rights to perform the requested operation.
    >>> Using the credentials of the 'current' process may be not appropriate in
    >>> case a file descriptor is opened by a kernel service (i.e. a filesystem)
    >>> and made shared among user processes. For instance, in a system with
    >>> SELinux and eCryptfs, if the process A opens an encrypted file, eCryptfs
    >>> obtains a file descriptor to access the correspondent inode in the lower
    >>> filesystem, labeled with the A's label.
    >>> If the process B accesses the same encrypted file, it needs the 'use'
    >>> permission on the A's label other than permissions for the lower inode.
    >>> However, if B is the first accessing process, A needs the 'use' permission
    >>> on the B's label.
    >> I am having trouble understanding the argument. I will pose my
    >> question in Smack terms, as I can speak most definitively in them.
    >> A process running with a Smack label "A" creates a file, and that
    >> file gets labeled "A", as it ought. If eCryptfs is behaving correctly
    >> this ought not change. If eCryptfs in encrypting the label it needs
    >> to do so in such a way as to be able to decrypt it prior to
    >> presentation to the vfs layer, where it will be used in an access
    >> check. When the process running with a Smack label "B" comes along
    >> the vfs code will check the fetched and possibly decrypted "A"
    >> against "B" and, unless there is an explicit Smack rule in place
    >> granting "B" access to "A", fail.
    >> What is the problem? What is eCryptfs doing that prevents this
    >> from working?
    > Hi Casey - I think what Roberto is getting at is the way eCryptfs uses
    > only one lower file per eCryptfs inode. Imagine that there are 5
    > files open for ~/secret/foo at the eCryptfs layer, only 1 file is going
    > to be open in the lower filesystem and all eCryptfs file operations will
    > be multiplexed through it.
    > To make things more complicated, if the eCryptfs file is opened for
    > writing, the lower file must be opened for reading and writing. This is
    > because a write operation requires eCryptfs to vfs_read() from the lower
    > filesystem, decrypt that data and then vfs_write() the new data.
    > If the lower file can't be opened O_RDWR by the calling process, the
    > request is handed off to a kernel thread to open the lower file on
    > behalf of the calling process. It is definitely ugly.

    Is eCryptfs handling xattrs? It needs to be if it isn't.

    > Roberto, I hope I correctly described the situation that you're trying
    > to address. Can you tell me why we can't have a 1:1 mapping of eCryptfs
    > files to lower files?
    > Instead of having just one lower file attached to the eCryptfs inode, we
    > could have a list of opened files. There would be one for each eCryptfs
    > file that was opened. ecryptfs_writepage() would have to pick, in a
    > somewhat random fashion, one of the lower files to use. Of course, we
    > would still need to solve the problem of opening the lower file O_RDWR
    > when the calling process is only allowed write access (I may have just
    > answered my own question of why the 1:1 mapping technique won't solve
    > this problem).
    > Tyler

     \ /
      Last update: 2011-04-28 01:59    [W:0.025 / U:5.240 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site