selinux policy for encrypted files

[Dominick Grift]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 12/10/2010 01:29 PM, Roberto Sassu wrote:
> On Thu, 09 Dec 2010 12:07 +0100, "Dominick Grift" <domg472 at gmail.com>
> wrote:
> On 12/09/2010 11:48 AM, Roberto Sassu wrote:
>>>> Hi all
>>>>
>>>> i want to write a policy for encrypted files.
>>>> In order to do this i created some new types which have the
>>>> name of the correspondent type used for non encrypted files,
>>>> with the prefix 'encrypted_'.
>>>> Then i need to define the policy for applications that need to
>>>> use these new types which is very similar to this defined
>>>> for original types, except that i want to take rules only
>>>> for the 'dir' and 'file' class.
> 
> And what are you trying to achieve with that with regard to security?
> 
> 
>> I think making a distinction between inodes that contain plaintext
>> data and those that contain encrypted content should improve how
>> security decisions must be taken for the latter type.
>> For instance, assigning to an encrypted file the label 'encrypted_etc_t'
>> allows to significantly reduce the number of domains that can access
>> it while keeping the same meaning of the 'etc_t' label.
> 

If some domains interact with encrypted_etc_t but not etc_t and vice
versa, then, in my view, it is best to manage access to encrypted_etc_t
in a separate interface.

Because else you get into issues where for example a domain that calls
"files_read_etc_files()" can also interact with encrypted_etc_t, whilst
that may not be required/desired.

>>>> What this the best way to define the policy? Do i have
>>>> to duplicate all required interfaces/templates or can i reuse
>>>> the existent code, for instance by adding a new parameter?
>>>>
>>>> I will show an example of what i'm trying to define.
>>>>
>>>> New type: encrypted_etc_t;
>>>>
>>>> Example interface:
>>>>
>>>> interface(`files_list_etc',`
>>>> 	gen_require(`
>>>> 		type etc_t;
>>>> 	')
>>>>
>>>> 	allow $1 etc_t:dir list_dir_perms;
>>>> ')
>>>>
>>>>
>>>> Added interface:
>>>>
>>>> interface(`files_list_encrypted_etc',`
>>>> 	gen_require(`
>>>> 		type encrypted_etc_t;
>>>> 	')
>>>>
>>>> 	allow $1 encrypted_etc_t:dir list_dir_perms;
>>>> ')
> 
> The above examples are exactly the same. In that case you would not even
> need to create anything new. Also why would you want to create this
> whole stuff new just to be able to exclude classes other then dir and
> file? How is that beneficial for the security point of view to you?
> 
> 
>> Ok, i choose this approach in order to minimize the effort required
>> to write a policy for newly introduced labels. Using different
>> interfaces allows to add an extra call only in desired application
>> policies. Further, i defined new rules only related to the file and
>> dir classes because, in the former case, i don't want to assign an
>> encrypted label to files which are symlinks pointing to unencrypted
>> inodes and in the latter case, because i need different directory
>> labels in order to configure type transitions correctly.
> 
> 
> Comments i made above asside: it does not make to many difference
> (afaict) whether you extend existing interfaces or create new ones. if
> it works, it works.
> 
>>>> --
>>>> selinux mailing list
>>>> selinux at lists.fedoraproject.org
>>>> https://admin.fedoraproject.org/mailman/listinfo/selinux
> 
- --
selinux mailing list
selinux at lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
>>

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk0CHqsACgkQMlxVo39jgT+z0gCfYdmfbi8xSmHqjEWVp/draMnI
o4YAn0fyNGx3OkFUL6uaIQi8I4FGTm0T
=pHYb
-----END PGP SIGNATURE-----