On 4/27/2011 4:27 PM, Tyler Hicks wrote: > On Wed Apr 27, 2011 at 01:19:55PM -0700, Casey Schaufler <casey@xxxxxxxxxxxxxxxx> 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 > > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
