lkml.org 
[lkml]   [2011]   [Apr]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC][PATCH 0/7] File descriptor labeling
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.



\
 
 \ /
  Last update: 2011-04-27 17:55    [W:2.215 / U:0.256 seconds]
©2003-2014 Jasper Spaans. Advertise on this site