ecryptfs-devel team mailing list archive

[Casey Schaufler <casey@xxxxxxxxxxxxxxxx>]

On 4/28/2011 5:35 AM, Roberto Sassu wrote:
> On Thursday, April 28, 2011 01:27:19 AM 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.
>>
>> 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).
>>
> Hi Tyler
>
> i think the 1:1 mapping isn't necessary at least from the security perspective.
> Since eCryptfs is a stacked filesystem access control is performed on
> both the upper and the lower layer.
> ECryptfs relies on the lower filesystem for the management of extended
> attributes, so this means that the security label of both the upper and
> the lower inodes is the same (however this is not the current behavior
> in SELinux, which assigns the label 'ecryptfs_t' to the upper inode).

Where does this assignment occur?

> In my view, for this reason the access control checks can be performed
> only at the upper layer, letting eCryptfs full privileges to access inodes
> in the lower filesystem.

On this point I most strongly disagree.

The behavior of a filesystem and the data that it uses to determine
that behavior is wrought with complex interactions which may include
but are not limited to caching, read-aheads, garbage collection,
and various side effects of access control. If eCryptfs needs to go
mucking about with the data used by the underlying filesystem it is
not stacking properly. A stacked filesystem has no business whatever
changing the data of the underlying filesystem.

> This solves the problem of opening the lower file in r/w mode even if only
> the read is requested, because at the upper layer the subject is the
> accessing process with its own credentials which needs the read permission
> and at the lower layer the subject is the eCryptfs kernel module with
> unlimited privileges.

Excuse my ignorance for a moment. Is eCryptfs a user mode filesystem,
or in the kernel properly? The behavior makes it sound like the former
while the interfaces you're requesting make it seem like the latter.

> The issue i described in the cover letter is related to the label assigned
> to the file descriptor obtained by eCryptfs (or another kernel service) when
> opening an inode in the lower filesystem, which actually depends on the
> first accessing process.
> This label is checked against the credentials of the 'current' process in the
> hook security_file_permission(), which is triggered by vfs calls (read, write,
> readdir) performed on both the upper and the lower inodes.
> In SELinux, a process needs the permission to 'use' a opened file descriptor.
> So, having a fixed label helps in defining the rule that must be added in the
> policy for eCryptfs to ensure it works properly.

I'm afraid to suggest this, but it looks as if you may be
able to solve your problems with some SELinux policy. I am
of course not an expert on SELinux policy, but it looks as
if not specifying an appropriate policy for the user space
component is what is in the way here.

> PS: i'm adding in CC the Apparmor's mantainer and the mailing list to have
> their opinion about the protection offered for the eCryptfs filesystem and
> other kernel services. The overall thread is available at the url:
>
> https://lkml.org/lkml/2011/4/27/201
>
> Thanks
>
> Roberto Sassu
>
>
>> Tyler
>>
>