* selinux policy for encrypted files
@ 2010-12-09 10:48 Roberto Sassu
[not found] ` <4D00B88A.9050704@gmail.com>
0 siblings, 1 reply; 3+ messages in thread
From: Roberto Sassu @ 2010-12-09 10:48 UTC (permalink / raw)
To: selinux; +Cc: selinux
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.
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;
')
--
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.
^ permalink raw reply [flat|nested] 3+ messages in thread[parent not found: <4D00B88A.9050704@gmail.com>]
* Re: selinux policy for encrypted files [not found] ` <4D00B88A.9050704@gmail.com> @ 2010-12-10 12:29 ` Roberto Sassu 2010-12-10 12:35 ` Dominick Grift 0 siblings, 1 reply; 3+ messages in thread From: Roberto Sassu @ 2010-12-10 12:29 UTC (permalink / raw) To: Dominick Grift; +Cc: selinux, selinux On Thu, 09 Dec 2010 12:07 +0100, "Dominick Grift" <domg472@gmail.com> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA1 > > 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. > > 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@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/ > > iEYEARECAAYFAk0AuIoACgkQMlxVo39jgT82owCePwRysaVkriSvqGQmqr88wDLU > 9KoAnj/H5TJKZD0+78M6hok+30x7eCfv > =BLwh > -----END PGP SIGNATURE----- > -- > selinux mailing list > selinux@lists.fedoraproject.org > https://admin.fedoraproject.org/mailman/listinfo/selinux > -- 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: selinux policy for encrypted files 2010-12-10 12:29 ` Roberto Sassu @ 2010-12-10 12:35 ` Dominick Grift 0 siblings, 0 replies; 3+ messages in thread From: Dominick Grift @ 2010-12-10 12:35 UTC (permalink / raw) To: Roberto Sassu; +Cc: selinux, selinux -----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@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@lists.fedoraproject.org >>>> https://admin.fedoraproject.org/mailman/listinfo/selinux > - -- selinux mailing list selinux@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----- -- 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. ^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2010-12-10 12:36 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2010-12-09 10:48 selinux policy for encrypted files Roberto Sassu
[not found] ` <4D00B88A.9050704@gmail.com>
2010-12-10 12:29 ` Roberto Sassu
2010-12-10 12:35 ` Dominick Grift
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.