-----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@xxxxxxxxx> > 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@xxxxxxxxxxxxxxxxxxxxxxx >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > - -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx 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----- -- selinux mailing list selinux@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/selinux
