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

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

[Roberto Sassu]

[-- Attachment #1: Type: text/plain, Size: 3428 bytes --]

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.

The solution proposed is to modify those kernel services that deal with
file descriptors to provide their set of credentials to dentry_open(), so
that obtained objects are labeled with a unique label. In this way, in the
above example, if eCryptfs provides its credentials with the label C to
dentry_open(), all user processes need the 'use' permission only on C.



File descriptor labeling and IMA

The above proposal suggests to use the file descriptor label as a new
criteria in the IMA policy to determine if a file must be measured. It will
be possible to measure all files opened by a kernel service by simply
writing a rule where the file descriptor label given as a value matches the
one provided by the same service together with other credentials to the
function dentry_open().

In the above example, if eCryptfs provides its credentials with the label C
to dentry_open(), it is possible to measure all inodes opened in the lower
filesystem by specifying a rule like:

fowner_type=C


The benefits of this new criteria will be greater with the integration of
EVM and the IMA appraisal feature in the kernel. ECryptfs can be used in
conjunction with these components to verify the integrity of the content
and extended attributes of encrypted files.

Roberto Sassu


Roberto Sassu (7):
  fs: initialize file->f_cred with credentials provided
  selinux: label new file descriptors using file->f_cred
  smack: assign the label set in file->f_cred to new file descriptors
  smack: fix label check in smack_kernel_act_as()
  smack: import the security label in smack_secctx_to_secid()
  security: new LSM hook security_file_getsecid()
  ima: added new LSM conditions in the policy

 Documentation/ABI/testing/ima_policy |    7 ++++-
 fs/file_table.c                      |    5 +--
 fs/internal.h                        |    2 +-
 fs/namei.c                           |    2 +-
 fs/open.c                            |    2 +-
 include/linux/security.h             |   12 +++++++++
 security/capability.c                |    6 ++++
 security/integrity/ima/ima.h         |    4 +-
 security/integrity/ima/ima_api.c     |    4 +-
 security/integrity/ima/ima_main.c    |    4 +-
 security/integrity/ima/ima_policy.c  |   45 +++++++++++++++++++++++++++++----
 security/security.c                  |    6 ++++
 security/selinux/hooks.c             |    9 ++++++-
 security/smack/smack_lsm.c           |   23 +++++++++++++++--
 14 files changed, 108 insertions(+), 23 deletions(-)

-- 
1.7.4.4


[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 2061 bytes --]

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

[Casey Schaufler]

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.
>
> The solution proposed is to modify those kernel services that deal with
> file descriptors to provide their set of credentials to dentry_open(), so
> that obtained objects are labeled with a unique label. In this way, in the
> above example, if eCryptfs provides its credentials with the label C to
> dentry_open(), all user processes need the 'use' permission only on C.
>
>
>
> File descriptor labeling and IMA
>
> The above proposal suggests to use the file descriptor label as a new
> criteria in the IMA policy to determine if a file must be measured. It will
> be possible to measure all files opened by a kernel service by simply
> writing a rule where the file descriptor label given as a value matches the
> one provided by the same service together with other credentials to the
> function dentry_open().
>
> In the above example, if eCryptfs provides its credentials with the label C
> to dentry_open(), it is possible to measure all inodes opened in the lower
> filesystem by specifying a rule like:
>
> fowner_type=C
>
>
> The benefits of this new criteria will be greater with the integration of
> EVM and the IMA appraisal feature in the kernel. ECryptfs can be used in
> conjunction with these components to verify the integrity of the content
> and extended attributes of encrypted files.
>
> Roberto Sassu
>
>
> Roberto Sassu (7):
>   fs: initialize file->f_cred with credentials provided
>   selinux: label new file descriptors using file->f_cred
>   smack: assign the label set in file->f_cred to new file descriptors
>   smack: fix label check in smack_kernel_act_as()
>   smack: import the security label in smack_secctx_to_secid()
>   security: new LSM hook security_file_getsecid()
>   ima: added new LSM conditions in the policy
>
>  Documentation/ABI/testing/ima_policy |    7 ++++-
>  fs/file_table.c                      |    5 +--
>  fs/internal.h                        |    2 +-
>  fs/namei.c                           |    2 +-
>  fs/open.c                            |    2 +-
>  include/linux/security.h             |   12 +++++++++
>  security/capability.c                |    6 ++++
>  security/integrity/ima/ima.h         |    4 +-
>  security/integrity/ima/ima_api.c     |    4 +-
>  security/integrity/ima/ima_main.c    |    4 +-
>  security/integrity/ima/ima_policy.c  |   45 +++++++++++++++++++++++++++++----
>  security/security.c                  |    6 ++++
>  security/selinux/hooks.c             |    9 ++++++-
>  security/smack/smack_lsm.c           |   23 +++++++++++++++--
>  14 files changed, 108 insertions(+), 23 deletions(-)

I have not given this patch set a complete review, but at first
glance I do not like it. You seem to be making a lot of assumptions
about the interactions between services and LSMs that I don't
know are valid. It is possible that I have not dug in deeply
enough to understand where this is headed. I will have a more
complete review in a bit.

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

[Casey Schaufler]

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?

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

[Tyler Hicks]

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.

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

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

[Casey Schaufler]

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
>
>

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

[Tyler Hicks]

On Wed Apr 27, 2011 at 04:57:42PM -0700, Casey Schaufler <casey@schaufler-ca.com> wrote:
> 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.

Yes - we pass the calls to the lower filesystem and return the result.

The only catch would be that users can opt to have eCryptfs store the
crypto metadata in user.ecryptfs instead of the first 8k of the file.

Tyler

> 
> > 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
> >
> >
> 

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

[Roberto Sassu]

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@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.
> 
> 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).
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.
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.
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.


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
> 

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

[Casey Schaufler]

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@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.
>>
>> 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
>>
>

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

[Eric Paris]

On Thu, Apr 28, 2011 at 1:37 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> 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@schaufler-ca.com> wrote:
>>>> On 4/27/2011 5:34 AM, Roberto Sassu wrote:

> On this point I most strongly disagree.


Casey, I'm glad you're trying to figure out what's going on here
because I certainly don't understand all the problems!

If there were some mechanism by which the 'lower' inode could be ONLY
accessibly by ecyptfs kernel internals it oculd be marked IS_PRIVATE
and skip all security checks on it.  Then you only have SELinux
security checks on the upper inode.  Which seems to make sense.  My
problem is that this is ONLY acceptable if there is no way for
userspace to directly reference the lower struct inode.

Just a thought.

-Eric

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

[Roberto Sassu]

[-- Attachment #1: Type: text/plain, Size: 9130 bytes --]

On Thursday, April 28, 2011 07:37:29 PM Casey Schaufler wrote:
> 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-iSGtlc1asvQWG2LlvL+J4A@public.gmane.org> 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?
> 

Hi Casey

The assignment happens at the inode's initialization time and depends on
the behavior configured for a specific filesystem.
The SELinux reference policy actually configures static labeling for inodes
in the eCryptfs filesystem while for example allows ext4 inodes to be
initialized using extended attributes.


> > 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.
> 

Ok, probably i have to go more in deep to explain how access control is
performed on eCryptfs. I'm talking for the SELinux's case, so SELinux experts
can correct me if i'm wrong.

First, i want to use extended attributes to initialize an eCryptfs inode, so
both the upper and the lower inodes have the same security context
because eCryptfs calls the *xattr() methods of the underlying filesystem.

Then, the process A accesses the eCryptfs inode 'I'. On the upper layer access
control is performed using the credentials of the 'current' process and the
security context of I.

If the process is allowed to access the upper inode, eCryptfs opens the lower
inode, presenting its own credentials with the type 'kernel_t'. Then, SELinux
checks if 'kernel_t' can access the inode with the security context of 'I'. If so,
eCryptfs obtains a file descriptor which, in this patch set, is labeled using the
same credentials it provided at open time and binds it to the upper inode.

Suppose for a moment that A is working on the eCryptfs inode 'I' and the process
B requests the same inode. ECryptfs uses the already opened file descriptor and
B will be granted to open the requested inode if:

- B has the 'open' permission on the upper inode 'I';


and can perform read/write operations if:

- B has the 'read' and 'write' permissions on the upper inode 'I';
- B is allowed to use the file descriptor opened by eCryptfs ('kernel_t').
- B has the 'read' and 'write' permissions on the lower inode I;


What i miss to say in my previous email is that even if eCryptfs is granted
to access inodes in the lower filesystem with full privileges, user processes
still need the permission to deal with the lower inode, but the check on the
upper inode is sufficient because the security context is the same.

Roberto Sassu


> > 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
> >>
> >
> 
> 

[-- Attachment #2: Type: text/html, Size: 37554 bytes --]

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

[Roberto Sassu]

Sorry for resending, it was rejected by the mailing lists due to
the html formatting.


On Thursday, April 28, 2011 07:37:29 PM Casey Schaufler wrote:
> 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@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.
> >>
> >> 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?
> 

Hi Casey

The assignment happens at the inode's initialization time and depends on
the behavior configured for a specific filesystem.
The SELinux reference policy actually configures static labeling for inodes
in the eCryptfs filesystem while for example allows ext4 inodes to be
initialized using extended attributes.


> > 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.
> 

Ok, probably i have to go more in deep to explain how access control is
performed on eCryptfs. I'm talking for the SELinux's case, so SELinux experts
can correct me if i'm wrong.

First, i want to use extended attributes to initialize an eCryptfs inode, so
both the upper and the lower inodes have the same security context
because eCryptfs calls the *xattr() methods of the underlying filesystem.

Then, the process A accesses the eCryptfs inode 'I'. On the upper layer access
control is performed using the credentials of the 'current' process and the
security context of I.

If the process is allowed to access the upper inode, eCryptfs opens the lower
inode, presenting its own credentials with the type 'kernel_t'. Then, SELinux
checks if 'kernel_t' can access the inode with the security context of 'I'. If so,
eCryptfs obtains a file descriptor which, in this patch set, is labeled using the
same credentials it provided at open time and binds it to the upper inode.

Suppose for a moment that A is working on the eCryptfs inode 'I' and the process
B requests the same inode. ECryptfs uses the already opened file descriptor and
B will be granted to open the requested inode if:

- B has the 'open' permission on the upper inode 'I';


and can perform read/write operations if:

- B has the 'read' and 'write' permissions on the upper inode 'I';
- B is allowed to use the file descriptor opened by eCryptfs ('kernel_t').
- B has the 'read' and 'write' permissions on the lower inode I;


What i miss to say in my previous email is that even if eCryptfs is granted
to access inodes in the lower filesystem with full privileges, user processes
still need the permission to deal with the lower inode, but the check on the
upper inode is sufficient because the security context is the same.

Roberto Sassu


> > 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
> >>
> >
> 
> 

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

[Casey Schaufler]

On 4/29/2011 2:39 AM, Roberto Sassu wrote:
> Sorry for resending, it was rejected by the mailing lists due to
> the html formatting.
>
>
> On Thursday, April 28, 2011 07:37:29 PM Casey Schaufler wrote:
>> 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@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.
>>>>
>>>> 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?
>>
> Hi Casey
>
> The assignment happens at the inode's initialization time and depends on
> the behavior configured for a specific filesystem.
> The SELinux reference policy actually configures static labeling for inodes
> in the eCryptfs filesystem while for example allows ext4 inodes to be
> initialized using extended attributes.

So how about changing eCryptfs (Goodness, but I hate camelCase) to
properly support extended attributes? That would seem a better
approach than mucking up the entire LSM. You still have to deal
with the SELinux policy, but I don't see you getting away without
doing something with that in any case.

>>> 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.
>>
> Ok, probably i have to go more in deep to explain how access control is
> performed on eCryptfs. I'm talking for the SELinux's case, so SELinux experts
> can correct me if i'm wrong.
>
> First, i want to use extended attributes to initialize an eCryptfs inode, so
> both the upper and the lower inodes have the same security context
> because eCryptfs calls the *xattr() methods of the underlying filesystem.

OK, you could create your own xattr functions that do whatever credential
mucking they need to and then call the underlying file system's version.
It is possible that the work the NFS people have been doing for xattr
support (I haven't seen much on this lately, is it still active? Anyone?)
would prove instructive.

> Then, the process A accesses the eCryptfs inode 'I'. On the upper layer access
> control is performed using the credentials of the 'current' process and the
> security context of I.
>
> If the process is allowed to access the upper inode, eCryptfs opens the lower
> inode, presenting its own credentials with the type 'kernel_t'.

So eCryptfs provides its own process context. When you say "open" do you
mean open(2) or something else? A little precision goes a long way in these
discussions.

> Then, SELinux
> checks if 'kernel_t' can access the inode with the security context of 'I'.

Why doesn't eCryptfs provide the credentials of 'I'? In the kernel you
can do what you will.

> If so,
> eCryptfs obtains a file descriptor which, in this patch set, is labeled using the
> same credentials it provided at open time and binds it to the upper inode.
>
> Suppose for a moment that A is working on the eCryptfs inode 'I' and the process
> B requests the same inode. ECryptfs uses the already opened file descriptor and
> B will be granted to open the requested inode if:
>
> - B has the 'open' permission on the upper inode 'I';
>
>
> and can perform read/write operations if:
>
> - B has the 'read' and 'write' permissions on the upper inode 'I';
> - B is allowed to use the file descriptor opened by eCryptfs ('kernel_t').
> - B has the 'read' and 'write' permissions on the lower inode I;
>
>
> What i miss to say in my previous email is that even if eCryptfs is granted
> to access inodes in the lower filesystem with full privileges, user processes
> still need the permission to deal with the lower inode, but the check on the
> upper inode is sufficient because the security context is the same.

Right, but what I don't understand is why you can't use existing
mechanisms to achieve this? NFS manages (mostly).

>> 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.

I'll repeat the question because it matters.

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

[Guido Trentalancia]

On Fri, 2011-04-29 at 08:46 -0700, Casey Schaufler wrote:
> On 4/29/2011 2:39 AM, Roberto Sassu wrote:
[cut]

> >> 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.
> 
> I'll repeat the question because it matters.

I am not an expert but since it's already the second time that you ask,
I have done a little of research and it seems that it's implemented in
the kernel and then it has userspace tools for management. So it
shouldn't be any different than other filesystems such as "extended
filesystems" (2,3,4)...

Regards,

Guido

> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo-+05T5uksL2qpZYMLLGbcSA@public.gmane.org with
> the words "unsubscribe selinux" without quotes as the message.
> 

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

[Roberto Sassu]

On Friday, April 29, 2011 05:46:20 PM Casey Schaufler wrote:
> On 4/29/2011 2:39 AM, Roberto Sassu wrote:
> > Sorry for resending, it was rejected by the mailing lists due to
> > the html formatting.
> >
> >
> > On Thursday, April 28, 2011 07:37:29 PM Casey Schaufler wrote:
> >> 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@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.
> >>>>
> >>>> 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?
> >>
> > Hi Casey
> >
> > The assignment happens at the inode's initialization time and depends on
> > the behavior configured for a specific filesystem.
> > The SELinux reference policy actually configures static labeling for inodes
> > in the eCryptfs filesystem while for example allows ext4 inodes to be
> > initialized using extended attributes.
> 
> So how about changing eCryptfs (Goodness, but I hate camelCase) to
> properly support extended attributes? That would seem a better
> approach than mucking up the entire LSM. You still have to deal
> with the SELinux policy, but I don't see you getting away without
> doing something with that in any case.
> 

Hi Casey

i think having separate extended attributes in eCryptfs does not
address the issue i reported in the cover letter.
The reason is, in my opinion, the incorrect labeling of file descriptors
which causes in SELinux more permissions than those really needed
must be added in the policy. This does not depends on the inode's
security context but on the credentials provided to dentry_open().


> >>> 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.
> >>
> > Ok, probably i have to go more in deep to explain how access control is
> > performed on eCryptfs. I'm talking for the SELinux's case, so SELinux experts
> > can correct me if i'm wrong.
> >
> > First, i want to use extended attributes to initialize an eCryptfs inode, so
> > both the upper and the lower inodes have the same security context
> > because eCryptfs calls the *xattr() methods of the underlying filesystem.
> 
> OK, you could create your own xattr functions that do whatever credential
> mucking they need to and then call the underlying file system's version.
> It is possible that the work the NFS people have been doing for xattr
> support (I haven't seen much on this lately, is it still active? Anyone?)
> would prove instructive.
> 
> > Then, the process A accesses the eCryptfs inode 'I'. On the upper layer access
> > control is performed using the credentials of the 'current' process and the
> > security context of I.
> >
> > If the process is allowed to access the upper inode, eCryptfs opens the lower
> > inode, presenting its own credentials with the type 'kernel_t'.
> 
> So eCryptfs provides its own process context. When you say "open" do you
> mean open(2) or something else? A little precision goes a long way in these
> discussions.
> 

ECryptfs provides its own credentials when calling the function dentry_open()
to obtain a file descriptor to be shared among user processes.


> > Then, SELinux
> > checks if 'kernel_t' can access the inode with the security context of 'I'.
> 
> Why doesn't eCryptfs provide the credentials of 'I'? In the kernel you
> can do what you will.
> 

No, eCryptfs provides (in the following patch) the 'initial' credentials which
are obtained through the function prepare_kernel_cred() which give root
privileges. These credentials are used in the hook security_dentry_open()
to verify if eCryptfs is allowed to access the inode 'I' in the underlying
filesystem.


> > If so,
> > eCryptfs obtains a file descriptor which, in this patch set, is labeled using the
> > same credentials it provided at open time and binds it to the upper inode.
> >
> > Suppose for a moment that A is working on the eCryptfs inode 'I' and the process
> > B requests the same inode. ECryptfs uses the already opened file descriptor and
> > B will be granted to open the requested inode if:
> >
> > - B has the 'open' permission on the upper inode 'I';
> >
> >
> > and can perform read/write operations if:
> >
> > - B has the 'read' and 'write' permissions on the upper inode 'I';
> > - B is allowed to use the file descriptor opened by eCryptfs ('kernel_t').
> > - B has the 'read' and 'write' permissions on the lower inode I;
> >
> >
> > What i miss to say in my previous email is that even if eCryptfs is granted
> > to access inodes in the lower filesystem with full privileges, user processes
> > still need the permission to deal with the lower inode, but the check on the
> > upper inode is sufficient because the security context is the same.
> 
> Right, but what I don't understand is why you can't use existing
> mechanisms to achieve this? NFS manages (mostly).
> 

Please, can you explain better this thought?


> >> 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.
> 
> I'll repeat the question because it matters.

As already reported by Guido Trentalancia, eCryptfs is a kernel mode
filesystem, which accepts data from the VFS layer, encrypts or decrypts
them and store the result in the underlying filesystem, always passing from
the VFS interface.

Roberto Sassu


> 
> 

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

[Casey Schaufler]

On 5/2/2011 1:53 AM, Roberto Sassu wrote:
> On Friday, April 29, 2011 05:46:20 PM Casey Schaufler wrote:
>> On 4/29/2011 2:39 AM, Roberto Sassu wrote:
>>> Sorry for resending, it was rejected by the mailing lists due to
>>> the html formatting.
>>>
>>>
>>> On Thursday, April 28, 2011 07:37:29 PM Casey Schaufler wrote:
>>>> 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@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.
>>>>>>
>>>>>> 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?
>>>>
>>> Hi Casey
>>>
>>> The assignment happens at the inode's initialization time and depends on
>>> the behavior configured for a specific filesystem.
>>> The SELinux reference policy actually configures static labeling for inodes
>>> in the eCryptfs filesystem while for example allows ext4 inodes to be
>>> initialized using extended attributes.
>> So how about changing eCryptfs (Goodness, but I hate camelCase) to
>> properly support extended attributes? That would seem a better
>> approach than mucking up the entire LSM. You still have to deal
>> with the SELinux policy, but I don't see you getting away without
>> doing something with that in any case.
>>
> Hi Casey
>
> i think having separate extended attributes in eCryptfs does not
> address the issue i reported in the cover letter.
> The reason is, in my opinion, the incorrect labeling of file descriptors
> which causes in SELinux more permissions than those really needed
> must be added in the policy. This does not depends on the inode's
> security context but on the credentials provided to dentry_open().

The problem is that you seem to think that eCryptfs needs
access to the file. If eCryptfs is kernel code being invoked
through the VFS you should be providing the user's credentials.

>
>>>>> 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.
>>>>
>>> Ok, probably i have to go more in deep to explain how access control is
>>> performed on eCryptfs. I'm talking for the SELinux's case, so SELinux experts
>>> can correct me if i'm wrong.
>>>
>>> First, i want to use extended attributes to initialize an eCryptfs inode, so
>>> both the upper and the lower inodes have the same security context
>>> because eCryptfs calls the *xattr() methods of the underlying filesystem.
>> OK, you could create your own xattr functions that do whatever credential
>> mucking they need to and then call the underlying file system's version.
>> It is possible that the work the NFS people have been doing for xattr
>> support (I haven't seen much on this lately, is it still active? Anyone?)
>> would prove instructive.
>>
>>> Then, the process A accesses the eCryptfs inode 'I'. On the upper layer access
>>> control is performed using the credentials of the 'current' process and the
>>> security context of I.
>>>
>>> If the process is allowed to access the upper inode, eCryptfs opens the lower
>>> inode, presenting its own credentials with the type 'kernel_t'.
>> So eCryptfs provides its own process context. When you say "open" do you
>> mean open(2) or something else? A little precision goes a long way in these
>> discussions.
>>
> ECryptfs provides its own credentials when calling the function dentry_open()
> to obtain a file descriptor to be shared among user processes.

This is your problem. The problem is that you are not
using the credential of the user process to access the
file, you are using your own. Sharing a "file descriptor"
may seem like an optimization, but as you see it has
does not work.

>>> Then, SELinux
>>> checks if 'kernel_t' can access the inode with the security context of 'I'.
>> Why doesn't eCryptfs provide the credentials of 'I'? In the kernel you
>> can do what you will.
> No, eCryptfs provides (in the following patch) the 'initial' credentials which
> are obtained through the function prepare_kernel_cred() which give root
> privileges. These credentials are used in the hook security_dentry_open()
> to verify if eCryptfs is allowed to access the inode 'I' in the underlying
> filesystem.

But you shouldn't care if eCryptfs can access the file. You should
only care if the user process can access the file. You're kernel code,
you can do what you will.

>>> If so,
>>> eCryptfs obtains a file descriptor which, in this patch set, is labeled using the
>>> same credentials it provided at open time and binds it to the upper inode.
>>>
>>> Suppose for a moment that A is working on the eCryptfs inode 'I' and the process
>>> B requests the same inode. ECryptfs uses the already opened file descriptor and
>>> B will be granted to open the requested inode if:
>>>
>>> - B has the 'open' permission on the upper inode 'I';
>>>
>>>
>>> and can perform read/write operations if:
>>>
>>> - B has the 'read' and 'write' permissions on the upper inode 'I';
>>> - B is allowed to use the file descriptor opened by eCryptfs ('kernel_t').
>>> - B has the 'read' and 'write' permissions on the lower inode I;
>>>
>>>
>>> What i miss to say in my previous email is that even if eCryptfs is granted
>>> to access inodes in the lower filesystem with full privileges, user processes
>>> still need the permission to deal with the lower inode, but the check on the
>>> upper inode is sufficient because the security context is the same.
>> Right, but what I don't understand is why you can't use existing
>> mechanisms to achieve this? NFS manages (mostly).
>>
> Please, can you explain better this thought?

NFS provides a network "view" of an ext4 (or any type for that matter)
filesystem. NFS does not support extended attributes, but there has been
ongoing work on that. It seems that if NFS does not require the kind
of changes you are requesting you shouldn't either.

>>>> 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.
>> I'll repeat the question because it matters.
> As already reported by Guido Trentalancia, eCryptfs is a kernel mode
> filesystem, which accepts data from the VFS layer, encrypts or decrypts
> them and store the result in the underlying filesystem, always passing from
> the VFS interface.
>
> Roberto Sassu
>
>
>>
> --
> This message was distributed to subscribers of the selinux mailing list.
> If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> the words "unsubscribe selinux" without quotes as the message.
>
>

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

[John Johansen]

On 05/03/2011 03:58 PM, Casey Schaufler wrote:
> On 5/2/2011 1:53 AM, Roberto Sassu wrote:
>> On Friday, April 29, 2011 05:46:20 PM Casey Schaufler wrote:
>>> On 4/29/2011 2:39 AM, Roberto Sassu wrote:
>>>> Sorry for resending, it was rejected by the mailing lists due to
>>>> the html formatting.
>>>>
>>>>
>>>> On Thursday, April 28, 2011 07:37:29 PM Casey Schaufler wrote:
>>>>> 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@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.
>>>>>>>
>>>>>>> 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?
>>>>>
>>>> Hi Casey
>>>>
>>>> The assignment happens at the inode's initialization time and depends on
>>>> the behavior configured for a specific filesystem.
>>>> The SELinux reference policy actually configures static labeling for inodes
>>>> in the eCryptfs filesystem while for example allows ext4 inodes to be
>>>> initialized using extended attributes.
>>> So how about changing eCryptfs (Goodness, but I hate camelCase) to
>>> properly support extended attributes? That would seem a better
>>> approach than mucking up the entire LSM. You still have to deal
>>> with the SELinux policy, but I don't see you getting away without
>>> doing something with that in any case.
>>>
>> Hi Casey
>>
>> i think having separate extended attributes in eCryptfs does not
>> address the issue i reported in the cover letter.
>> The reason is, in my opinion, the incorrect labeling of file descriptors
>> which causes in SELinux more permissions than those really needed
>> must be added in the policy. This does not depends on the inode's
>> security context but on the credentials provided to dentry_open().
> 
> The problem is that you seem to think that eCryptfs needs
> access to the file. If eCryptfs is kernel code being invoked
> through the VFS you should be providing the user's credentials.
> 
I have to agree with Casey, Generally looping back through the vfs should
be using the user's credentials.  This doesn't even stop you opening the
lower file with a different set of permissions (eg.  rw while the upper
is opened with r).

>>
>>>>>> 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.
>>>>>
>>>> Ok, probably i have to go more in deep to explain how access control is
>>>> performed on eCryptfs. I'm talking for the SELinux's case, so SELinux experts
>>>> can correct me if i'm wrong.
>>>>
>>>> First, i want to use extended attributes to initialize an eCryptfs inode, so
>>>> both the upper and the lower inodes have the same security context
>>>> because eCryptfs calls the *xattr() methods of the underlying filesystem.
>>> OK, you could create your own xattr functions that do whatever credential
>>> mucking they need to and then call the underlying file system's version.
>>> It is possible that the work the NFS people have been doing for xattr
>>> support (I haven't seen much on this lately, is it still active? Anyone?)
>>> would prove instructive.
>>>
>>>> Then, the process A accesses the eCryptfs inode 'I'. On the upper layer access
>>>> control is performed using the credentials of the 'current' process and the
>>>> security context of I.
>>>>
>>>> If the process is allowed to access the upper inode, eCryptfs opens the lower
>>>> inode, presenting its own credentials with the type 'kernel_t'.
>>> So eCryptfs provides its own process context. When you say "open" do you
>>> mean open(2) or something else? A little precision goes a long way in these
>>> discussions.
>>>
>> ECryptfs provides its own credentials when calling the function dentry_open()
>> to obtain a file descriptor to be shared among user processes.
> 
> This is your problem. The problem is that you are not
> using the credential of the user process to access the
> file, you are using your own. Sharing a "file descriptor"
> may seem like an optimization, but as you see it has
> does not work.
> 
and I would add may behave differently dependent on the LSM

>>>> Then, SELinux
>>>> checks if 'kernel_t' can access the inode with the security context of 'I'.
>>> Why doesn't eCryptfs provide the credentials of 'I'? In the kernel you
>>> can do what you will.
>> No, eCryptfs provides (in the following patch) the 'initial' credentials which
>> are obtained through the function prepare_kernel_cred() which give root
>> privileges. These credentials are used in the hook security_dentry_open()
>> to verify if eCryptfs is allowed to access the inode 'I' in the underlying
>> filesystem.
> 
> But you shouldn't care if eCryptfs can access the file. You should
> only care if the user process can access the file. You're kernel code,
> you can do what you will.
> 
Agreed, the decision should be based off whether the user can access the file.

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

[Roberto Sassu]

On Wednesday, May 04, 2011 01:58:00 AM John Johansen wrote:
> On 05/03/2011 03:58 PM, Casey Schaufler wrote:
> > On 5/2/2011 1:53 AM, Roberto Sassu wrote:
> >> On Friday, April 29, 2011 05:46:20 PM Casey Schaufler wrote:
> >>> On 4/29/2011 2:39 AM, Roberto Sassu wrote:
> >>>> Sorry for resending, it was rejected by the mailing lists due to
> >>>> the html formatting.
> >>>>
> >>>>
> >>>> On Thursday, April 28, 2011 07:37:29 PM Casey Schaufler wrote:
> >>>>> 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@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.
> >>>>>>>
> >>>>>>> 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?
> >>>>>
> >>>> Hi Casey
> >>>>
> >>>> The assignment happens at the inode's initialization time and depends on
> >>>> the behavior configured for a specific filesystem.
> >>>> The SELinux reference policy actually configures static labeling for inodes
> >>>> in the eCryptfs filesystem while for example allows ext4 inodes to be
> >>>> initialized using extended attributes.
> >>> So how about changing eCryptfs (Goodness, but I hate camelCase) to
> >>> properly support extended attributes? That would seem a better
> >>> approach than mucking up the entire LSM. You still have to deal
> >>> with the SELinux policy, but I don't see you getting away without
> >>> doing something with that in any case.
> >>>
> >> Hi Casey
> >>
> >> i think having separate extended attributes in eCryptfs does not
> >> address the issue i reported in the cover letter.
> >> The reason is, in my opinion, the incorrect labeling of file descriptors
> >> which causes in SELinux more permissions than those really needed
> >> must be added in the policy. This does not depends on the inode's
> >> security context but on the credentials provided to dentry_open().
> > 
> > The problem is that you seem to think that eCryptfs needs
> > access to the file. If eCryptfs is kernel code being invoked
> > through the VFS you should be providing the user's credentials.
> > 
> I have to agree with Casey, Generally looping back through the vfs should
> be using the user's credentials.  This doesn't even stop you opening the
> lower file with a different set of permissions (eg.  rw while the upper
> is opened with r).
> 

Hi Casey and John

my patch set does not modify this behavior:  VFS calls on upper inodes
made by user processes and VFS calls (read/write) made by eCryptfs
on lower inodes still use the user's credentials.

In addition, SELinux provide a model for file descriptors. They may be
opened by another subject (which provided its own credentials) and
other processes need the 'use' permission for those file descriptors
other than permissions for related inodes.

This means that, even if eCryptfs opens lower inodes with its own
credentials, user processes still need permissions to read/write both
upper and lower inodes.

One benefit of allowing eCryptfs to provide its own credentials is that
user processes must have granted only strictly required permissions.

Roberto Sassu


> >>
> >>>>>> 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.
> >>>>>
> >>>> Ok, probably i have to go more in deep to explain how access control is
> >>>> performed on eCryptfs. I'm talking for the SELinux's case, so SELinux experts
> >>>> can correct me if i'm wrong.
> >>>>
> >>>> First, i want to use extended attributes to initialize an eCryptfs inode, so
> >>>> both the upper and the lower inodes have the same security context
> >>>> because eCryptfs calls the *xattr() methods of the underlying filesystem.
> >>> OK, you could create your own xattr functions that do whatever credential
> >>> mucking they need to and then call the underlying file system's version.
> >>> It is possible that the work the NFS people have been doing for xattr
> >>> support (I haven't seen much on this lately, is it still active? Anyone?)
> >>> would prove instructive.
> >>>
> >>>> Then, the process A accesses the eCryptfs inode 'I'. On the upper layer access
> >>>> control is performed using the credentials of the 'current' process and the
> >>>> security context of I.
> >>>>
> >>>> If the process is allowed to access the upper inode, eCryptfs opens the lower
> >>>> inode, presenting its own credentials with the type 'kernel_t'.
> >>> So eCryptfs provides its own process context. When you say "open" do you
> >>> mean open(2) or something else? A little precision goes a long way in these
> >>> discussions.
> >>>
> >> ECryptfs provides its own credentials when calling the function dentry_open()
> >> to obtain a file descriptor to be shared among user processes.
> > 
> > This is your problem. The problem is that you are not
> > using the credential of the user process to access the
> > file, you are using your own. Sharing a "file descriptor"
> > may seem like an optimization, but as you see it has
> > does not work.
> > 
> and I would add may behave differently dependent on the LSM
> 
> >>>> Then, SELinux
> >>>> checks if 'kernel_t' can access the inode with the security context of 'I'.
> >>> Why doesn't eCryptfs provide the credentials of 'I'? In the kernel you
> >>> can do what you will.
> >> No, eCryptfs provides (in the following patch) the 'initial' credentials which
> >> are obtained through the function prepare_kernel_cred() which give root
> >> privileges. These credentials are used in the hook security_dentry_open()
> >> to verify if eCryptfs is allowed to access the inode 'I' in the underlying
> >> filesystem.
> > 
> > But you shouldn't care if eCryptfs can access the file. You should
> > only care if the user process can access the file. You're kernel code,
> > you can do what you will.
> > 
> Agreed, the decision should be based off whether the user can access the file.
> 

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

[Roberto Sassu]

On Wednesday, May 04, 2011 12:58:48 AM Casey Schaufler wrote:
> On 5/2/2011 1:53 AM, Roberto Sassu wrote:
> > On Friday, April 29, 2011 05:46:20 PM Casey Schaufler wrote:
> >> On 4/29/2011 2:39 AM, Roberto Sassu wrote:
> >>> Sorry for resending, it was rejected by the mailing lists due to
> >>> the html formatting.
> >>>
> >>>
> >>> On Thursday, April 28, 2011 07:37:29 PM Casey Schaufler wrote:
> >>>> 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@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.
> >>>>>>
> >>>>>> 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?
> >>>>
> >>> Hi Casey
> >>>
> >>> The assignment happens at the inode's initialization time and depends on
> >>> the behavior configured for a specific filesystem.
> >>> The SELinux reference policy actually configures static labeling for inodes
> >>> in the eCryptfs filesystem while for example allows ext4 inodes to be
> >>> initialized using extended attributes.
> >> So how about changing eCryptfs (Goodness, but I hate camelCase) to
> >> properly support extended attributes? That would seem a better
> >> approach than mucking up the entire LSM. You still have to deal
> >> with the SELinux policy, but I don't see you getting away without
> >> doing something with that in any case.
> >>
> > Hi Casey
> >
> > i think having separate extended attributes in eCryptfs does not
> > address the issue i reported in the cover letter.
> > The reason is, in my opinion, the incorrect labeling of file descriptors
> > which causes in SELinux more permissions than those really needed
> > must be added in the policy. This does not depends on the inode's
> > security context but on the credentials provided to dentry_open().
> 
> The problem is that you seem to think that eCryptfs needs
> access to the file. If eCryptfs is kernel code being invoked
> through the VFS you should be providing the user's credentials.
> 
> >
> >>>>> 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.
> >>>>
> >>> Ok, probably i have to go more in deep to explain how access control is
> >>> performed on eCryptfs. I'm talking for the SELinux's case, so SELinux experts
> >>> can correct me if i'm wrong.
> >>>
> >>> First, i want to use extended attributes to initialize an eCryptfs inode, so
> >>> both the upper and the lower inodes have the same security context
> >>> because eCryptfs calls the *xattr() methods of the underlying filesystem.
> >> OK, you could create your own xattr functions that do whatever credential
> >> mucking they need to and then call the underlying file system's version.
> >> It is possible that the work the NFS people have been doing for xattr
> >> support (I haven't seen much on this lately, is it still active? Anyone?)
> >> would prove instructive.
> >>
> >>> Then, the process A accesses the eCryptfs inode 'I'. On the upper layer access
> >>> control is performed using the credentials of the 'current' process and the
> >>> security context of I.
> >>>
> >>> If the process is allowed to access the upper inode, eCryptfs opens the lower
> >>> inode, presenting its own credentials with the type 'kernel_t'.
> >> So eCryptfs provides its own process context. When you say "open" do you
> >> mean open(2) or something else? A little precision goes a long way in these
> >> discussions.
> >>
> > ECryptfs provides its own credentials when calling the function dentry_open()
> > to obtain a file descriptor to be shared among user processes.
> 
> This is your problem. The problem is that you are not
> using the credential of the user process to access the
> file, you are using your own. Sharing a "file descriptor"
> may seem like an optimization, but as you see it has
> does not work.
> 
> >>> Then, SELinux
> >>> checks if 'kernel_t' can access the inode with the security context of 'I'.
> >> Why doesn't eCryptfs provide the credentials of 'I'? In the kernel you
> >> can do what you will.
> > No, eCryptfs provides (in the following patch) the 'initial' credentials which
> > are obtained through the function prepare_kernel_cred() which give root
> > privileges. These credentials are used in the hook security_dentry_open()
> > to verify if eCryptfs is allowed to access the inode 'I' in the underlying
> > filesystem.
> 
> But you shouldn't care if eCryptfs can access the file. You should
> only care if the user process can access the file. You're kernel code,
> you can do what you will.
> 
> >>> If so,
> >>> eCryptfs obtains a file descriptor which, in this patch set, is labeled using the
> >>> same credentials it provided at open time and binds it to the upper inode.
> >>>
> >>> Suppose for a moment that A is working on the eCryptfs inode 'I' and the process
> >>> B requests the same inode. ECryptfs uses the already opened file descriptor and
> >>> B will be granted to open the requested inode if:
> >>>
> >>> - B has the 'open' permission on the upper inode 'I';
> >>>
> >>>
> >>> and can perform read/write operations if:
> >>>
> >>> - B has the 'read' and 'write' permissions on the upper inode 'I';
> >>> - B is allowed to use the file descriptor opened by eCryptfs ('kernel_t').
> >>> - B has the 'read' and 'write' permissions on the lower inode I;
> >>>
> >>>
> >>> What i miss to say in my previous email is that even if eCryptfs is granted
> >>> to access inodes in the lower filesystem with full privileges, user processes
> >>> still need the permission to deal with the lower inode, but the check on the
> >>> upper inode is sufficient because the security context is the same.
> >> Right, but what I don't understand is why you can't use existing
> >> mechanisms to achieve this? NFS manages (mostly).
> >>
> > Please, can you explain better this thought?
> 
> NFS provides a network "view" of an ext4 (or any type for that matter)
> filesystem. NFS does not support extended attributes, but there has been
> ongoing work on that. It seems that if NFS does not require the kind
> of changes you are requesting you shouldn't either.
> 

I'm not familiar with NFS, so i cannot answer about this scenario.
I'm adding in CC also the NFS mantainers and the mailing list so
that they can express their point of view. The whole thread is
available at:

https://lkml.org/lkml/2011/4/27/201

Roberto Sassu


> >>>> 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.
> >> I'll repeat the question because it matters.
> > As already reported by Guido Trentalancia, eCryptfs is a kernel mode
> > filesystem, which accepts data from the VFS layer, encrypts or decrypts
> > them and store the result in the underlying filesystem, always passing from
> > the VFS interface.
> >
> > Roberto Sassu
> >
> >
> >>
> > --
> > This message was distributed to subscribers of the selinux mailing list.
> > If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
> > the words "unsubscribe selinux" without quotes as the message.
> >
> >
> 
> 

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

[Casey Schaufler]

On 5/4/2011 1:47 AM, Roberto Sassu wrote:
> On Wednesday, May 04, 2011 01:58:00 AM John Johansen wrote:
>> ....
>> I have to agree with Casey, Generally looping back through the vfs should
>> be using the user's credentials.  This doesn't even stop you opening the
>> lower file with a different set of permissions (eg.  rw while the upper
>> is opened with r).
> Hi Casey and John
>
> my patch set does not modify this behavior:  VFS calls on upper inodes
> made by user processes and VFS calls (read/write) made by eCryptfs
> on lower inodes still use the user's credentials.
>
> In addition, SELinux provide a model for file descriptors. They may be
> opened by another subject (which provided its own credentials) and
> other processes need the 'use' permission for those file descriptors
> other than permissions for related inodes.
>
> This means that, even if eCryptfs opens lower inodes with its own
> credentials, user processes still need permissions to read/write both
> upper and lower inodes.
>
> One benefit of allowing eCryptfs to provide its own credentials is that
> user processes must have granted only strictly required permissions.
>
> Roberto Sassu

My point is that you should be able to achieve all of what you
say you want to do without introducing the LSM changes you are
proposing.

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

[Casey Schaufler]

On 5/4/2011 2:19 AM, Roberto Sassu wrote:
> On Wednesday, May 04, 2011 12:58:48 AM Casey Schaufler wrote:
>> On 5/2/2011 1:53 AM, Roberto Sassu wrote:
>> ...
>>>> Right, but what I don't understand is why you can't use existing
>>>> mechanisms to achieve this? NFS manages (mostly).
>>> Please, can you explain better this thought?
>> NFS provides a network "view" of an ext4 (or any type for that matter)
>> filesystem. NFS does not support extended attributes, but there has been
>> ongoing work on that. It seems that if NFS does not require the kind
>> of changes you are requesting you shouldn't either.
> I'm not familiar with NFS, so i cannot answer about this scenario.

NFS provides the historical and prototypical example of a layered
filesystem. If you are implementing a layered filesystem and have
not researched NFS you are missing out on the bulk of the experience
and wisdom on the subject.

> I'm adding in CC also the NFS mantainers and the mailing list so
> that they can express their point of view. The whole thread is
> available at:
>
> https://lkml.org/lkml/2011/4/27/201
>
> Roberto Sassu