Re: [RFC][PATCH 0/7] File descriptor labeling

[Casey Schaufler <casey@schaufler-ca.com>]

On 4/27/2011 4:27 PM, Tyler Hicks wrote:
> On Wed Apr 27, 2011 at 01:19:55PM -0700, Casey Schaufler <casey@schaufler-ca.com> 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
>
>