* [refpolicy] Policy modules design guidelines? @ 2011-01-12 20:46 Sven Vermeulen 2011-01-13 19:52 ` Christopher J. PeBenito 0 siblings, 1 reply; 10+ messages in thread From: Sven Vermeulen @ 2011-01-12 20:46 UTC (permalink / raw) To: refpolicy Hi list I'm slowly writing modules for applications that I cannot find modules for in the reference policy or elsewhere. My main goal is to have policies for all applications that have some network connectivity or work with data received by untrusted parties (such as an e-mail client). During the development I've found it difficult to know what the proper approach is concerning a few setups. From the #selinux mailinglist I gather that many of these approaches are mainly depending on the author (no wrong or right approach) but before submitting modules to the mailinglist for review (and potential inclusion) I thought of asking the following questions first ;-) - In case of application-specific modules (mozilla, pan, mutt, ...) is there a preferred method for handling the definitions? There are modules (such as for mozilla) that have the majority of the AV rules in the .te file and a somewhat straightforward role interface in .if, whereas others like screen have a straightforward .te file (more of a definition) whereas the .if file has a template (allowing for the generation of <role>_screen_t domains) - When writing policies on one system, chances are very high that this policy is not sufficient on other systems (especially other distributions). Is it okay to present the policy when tested on a single platform (so that others can check it and perhaps update it) or would you rather see the request for inclusion only after a distribution (or two) have included it in their releases? - One module I'm working on (Skype) has shown me that Skype likes reading things in the users' mozilla/firefox files (~/.mozilla/.../sec8.db and prefs.js), most likely to check if the Skype plugin is installed. I personally would not want to have this allowed, but I can imagine that the reference policy doesn't want to prevent activities that are normal behavior. Is that correct? - How much in-line documentation would reference policy suggestions have? Does it make sense to document (as comments) reasons why certain interfaces are called in the .te description? I noticed that not that many modules have much comments beyond the structural separation (to split the policy in related blocks)? - If an application really requires a permission to be granted (say execmem) but a more global boolean exists (allow_execmem) does reference policy want the module to honor the boolean, or should this only be when both states of the boolean still offer (some) functionality (like allow_dmesg)? Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-12 20:46 [refpolicy] Policy modules design guidelines? Sven Vermeulen @ 2011-01-13 19:52 ` Christopher J. PeBenito 2011-01-13 20:30 ` Dominick Grift 0 siblings, 1 reply; 10+ messages in thread From: Christopher J. PeBenito @ 2011-01-13 19:52 UTC (permalink / raw) To: refpolicy On 01/12/11 15:46, Sven Vermeulen wrote: > Hi list > > I'm slowly writing modules for applications that I cannot find modules for > in the reference policy or elsewhere. My main goal is to have policies for > all applications that have some network connectivity or work with data > received by untrusted parties (such as an e-mail client). > > During the development I've found it difficult to know what the proper > approach is concerning a few setups. From the #selinux mailinglist I gather > that many of these approaches are mainly depending on the author (no wrong > or right approach) but before submitting modules to the mailinglist for > review (and potential inclusion) I thought of asking the following questions > first ;-) > > - In case of application-specific modules (mozilla, pan, mutt, ...) is there > a preferred method for handling the definitions? There are modules (such > as for mozilla) that have the majority of the AV rules in the .te file and > a somewhat straightforward role interface in .if, whereas others like > screen have a straightforward .te file (more of a definition) whereas the > .if file has a template (allowing for the generation of <role>_screen_t > domains) There is a key difference between these two sets of modules. In most cases, you want it like mozilla, where nearly all the rules are in the .te and the role interface is simple. The few apps like screen have a different problem. They have a transition into the app, and then back out to the user domain (e.g. a shell running in the user's domain exec's screen which exec's a new shell in the user's domain). For that to work right, either you need a SELinux-aware app, or per-role application domains. > - When writing policies on one system, chances are very high that this > policy is not sufficient on other systems (especially other > distributions). Is it okay to present the policy when tested on a single > platform (so that others can check it and perhaps update it) or would you > rather see the request for inclusion only after a distribution (or two) > have included it in their releases? One distro test is fine. The other distro maintainers can tweak it as necessary. The use of distro build options is also preferred: where possible (and reasonable) distro-specific behaviors should be separated out into the distro_* build options. > - One module I'm working on (Skype) has shown me that Skype likes reading > things in the users' mozilla/firefox files (~/.mozilla/.../sec8.db and > prefs.js), most likely to check if the Skype plugin is installed. I > personally would not want to have this allowed, but I can imagine that the > reference policy doesn't want to prevent activities that are normal > behavior. Is that correct? It depends on why this is happening. If you have clicked a link in a Skype IM chat and firefox is running in the wrong domain (in skype_t or whatever), then we definitely want to fix that, not add access for skype_t. If Skype is just accessing the files, then justification for the access would need to be provided, since on the surface it looks like inappropriate access. > - How much in-line documentation would reference policy suggestions have? > Does it make sense to document (as comments) reasons why certain > interfaces are called in the .te description? I noticed that not that many > modules have much comments beyond the structural separation (to split the > policy in related blocks)? We're happy to have additional documentation, as long as its useful, and most of all, correct. Obviously comments like this would not be useful: # do dns lookups sysnet_dns_name_resolve(my_app_t) > - If an application really requires a permission to be granted (say execmem) > but a more global boolean exists (allow_execmem) does reference policy > want the module to honor the boolean, or should this only be when both > states of the boolean still offer (some) functionality (like allow_dmesg)? If the app intrinsically requires execmem, then just allow it unconditionally. An example is java. If you want to use java app, you have to accept the risk of having execmem. The conditionals/tunables follow the logic of the code. In your allow_dmesg example, its up to the admin to decide if users can run dmesg. It won't break user domains if they can't dmesg. So it makes sense to have this security-relevant decision exposed in the policy via a tunable. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-13 19:52 ` Christopher J. PeBenito @ 2011-01-13 20:30 ` Dominick Grift 2011-01-13 20:37 ` Daniel J Walsh 2011-01-15 21:03 ` Sven Vermeulen 0 siblings, 2 replies; 10+ messages in thread From: Dominick Grift @ 2011-01-13 20:30 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2011 08:52 PM, Christopher J. PeBenito wrote: > On 01/12/11 15:46, Sven Vermeulen wrote: >> Hi list >> >> I'm slowly writing modules for applications that I cannot find modules for >> in the reference policy or elsewhere. My main goal is to have policies for >> all applications that have some network connectivity or work with data >> received by untrusted parties (such as an e-mail client). >> >> During the development I've found it difficult to know what the proper >> approach is concerning a few setups. From the #selinux mailinglist I gather >> that many of these approaches are mainly depending on the author (no wrong >> or right approach) but before submitting modules to the mailinglist for >> review (and potential inclusion) I thought of asking the following questions >> first ;-) >> >> - In case of application-specific modules (mozilla, pan, mutt, ...) is there >> a preferred method for handling the definitions? There are modules (such >> as for mozilla) that have the majority of the AV rules in the .te file and >> a somewhat straightforward role interface in .if, whereas others like >> screen have a straightforward .te file (more of a definition) whereas the >> .if file has a template (allowing for the generation of <role>_screen_t >> domains) > > There is a key difference between these two sets of modules. In most > cases, you want it like mozilla, where nearly all the rules are in the > .te and the role interface is simple. The few apps like screen have a > different problem. They have a transition into the app, and then back > out to the user domain (e.g. a shell running in the user's domain exec's > screen which exec's a new shell in the user's domain). For that to work > right, either you need a SELinux-aware app, or per-role application domains. My opinion on this is different and the mozilla example is a good example as to why my opinion is different. My opinion is that it is preferred to use the per role template with the role prefixes, as this does not hurt and it offers flexibility for cases that may not have been foreseen. Like mozilla, in refpolicy mozilla is not prefixed. For this reason i had to redo mozilla policy in my policy that is built on reference policy. I think refpolicy should be as general as possible. With that i mean it should be usable whichever way you want to go with you customized policy. Back to mozilla, i have confined thunderbird as well. As you may know thunderbird can run firefox (click a URL in a mail messages) and firefox can run thunderbird (send link..) So firefox needs to transition to thunderbird and vice versa. But in a confined user space you will may want to want different firefox policy depending on who runs it. Therefore you need to prefix the firefox and thunderbird domains. examples: user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t This is why i prefer the prefix domains. It does not hurt to use them and who knows, you may need it later (and my experience says that many user apps are able to run other agents) my two cents >> - When writing policies on one system, chances are very high that this >> policy is not sufficient on other systems (especially other >> distributions). Is it okay to present the policy when tested on a single >> platform (so that others can check it and perhaps update it) or would you >> rather see the request for inclusion only after a distribution (or two) >> have included it in their releases? > > One distro test is fine. The other distro maintainers can tweak it as > necessary. The use of distro build options is also preferred: where > possible (and reasonable) distro-specific behaviors should be separated > out into the distro_* build options. > >> - One module I'm working on (Skype) has shown me that Skype likes reading >> things in the users' mozilla/firefox files (~/.mozilla/.../sec8.db and >> prefs.js), most likely to check if the Skype plugin is installed. I >> personally would not want to have this allowed, but I can imagine that the >> reference policy doesn't want to prevent activities that are normal >> behavior. Is that correct? > > It depends on why this is happening. If you have clicked a link in a > Skype IM chat and firefox is running in the wrong domain (in skype_t or > whatever), then we definitely want to fix that, not add access for > skype_t. If Skype is just accessing the files, then justification for > the access would need to be provided, since on the surface it looks like > inappropriate access. > >> - How much in-line documentation would reference policy suggestions have? >> Does it make sense to document (as comments) reasons why certain >> interfaces are called in the .te description? I noticed that not that many >> modules have much comments beyond the structural separation (to split the >> policy in related blocks)? > > We're happy to have additional documentation, as long as its useful, and > most of all, correct. Obviously comments like this would not be useful: > > # do dns lookups > sysnet_dns_name_resolve(my_app_t) > >> - If an application really requires a permission to be granted (say execmem) >> but a more global boolean exists (allow_execmem) does reference policy >> want the module to honor the boolean, or should this only be when both >> states of the boolean still offer (some) functionality (like allow_dmesg)? > > If the app intrinsically requires execmem, then just allow it > unconditionally. An example is java. If you want to use java app, you > have to accept the risk of having execmem. > > The conditionals/tunables follow the logic of the code. In your > allow_dmesg example, its up to the admin to decide if users can run > dmesg. It won't break user domains if they can't dmesg. So it makes > sense to have this security-relevant decision exposed in the policy via > a tunable. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vYNsACgkQMlxVo39jgT+Q5ACeLkC3LlIrEjzrZdVQ4VpqmFW7 cxEAoLwvKRO5FfU7FWn7G21A5WC7HzGO =LVdN -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-13 20:30 ` Dominick Grift @ 2011-01-13 20:37 ` Daniel J Walsh 2011-01-15 21:03 ` Sven Vermeulen 1 sibling, 0 replies; 10+ messages in thread From: Daniel J Walsh @ 2011-01-13 20:37 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/13/2011 03:30 PM, Dominick Grift wrote: > On 01/13/2011 08:52 PM, Christopher J. PeBenito wrote: >> On 01/12/11 15:46, Sven Vermeulen wrote: >>> Hi list >>> >>> I'm slowly writing modules for applications that I cannot find modules for >>> in the reference policy or elsewhere. My main goal is to have policies for >>> all applications that have some network connectivity or work with data >>> received by untrusted parties (such as an e-mail client). >>> >>> During the development I've found it difficult to know what the proper >>> approach is concerning a few setups. From the #selinux mailinglist I gather >>> that many of these approaches are mainly depending on the author (no wrong >>> or right approach) but before submitting modules to the mailinglist for >>> review (and potential inclusion) I thought of asking the following questions >>> first ;-) >>> >>> - In case of application-specific modules (mozilla, pan, mutt, ...) is there >>> a preferred method for handling the definitions? There are modules (such >>> as for mozilla) that have the majority of the AV rules in the .te file and >>> a somewhat straightforward role interface in .if, whereas others like >>> screen have a straightforward .te file (more of a definition) whereas the >>> .if file has a template (allowing for the generation of <role>_screen_t >>> domains) > >> There is a key difference between these two sets of modules. In most >> cases, you want it like mozilla, where nearly all the rules are in the >> .te and the role interface is simple. The few apps like screen have a >> different problem. They have a transition into the app, and then back >> out to the user domain (e.g. a shell running in the user's domain exec's >> screen which exec's a new shell in the user's domain). For that to work >> right, either you need a SELinux-aware app, or per-role application domains. > > My opinion on this is different and the mozilla example is a good > example as to why my opinion is different. > > My opinion is that it is preferred to use the per role template with the > role prefixes, as this does not hurt and it offers flexibility for cases > that may not have been foreseen. > > Like mozilla, in refpolicy mozilla is not prefixed. For this reason i > had to redo mozilla policy in my policy that is built on reference > policy. I think refpolicy should be as general as possible. With that i > mean it should be usable whichever way you want to go with you > customized policy. > > Back to mozilla, i have confined thunderbird as well. As you may know > thunderbird can run firefox (click a URL in a mail messages) and firefox > can run thunderbird (send link..) > > So firefox needs to transition to thunderbird and vice versa. But in a > confined user space you will may want to want different firefox policy > depending on who runs it. Therefore you need to prefix the firefox and > thunderbird domains. > > examples: > > user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t > staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t > > This is why i prefer the prefix domains. It does not hurt to use them > and who knows, you may need it later (and my experience says that many > user apps are able to run other agents) > > my two cents > >>> - When writing policies on one system, chances are very high that this >>> policy is not sufficient on other systems (especially other >>> distributions). Is it okay to present the policy when tested on a single >>> platform (so that others can check it and perhaps update it) or would you >>> rather see the request for inclusion only after a distribution (or two) >>> have included it in their releases? > >> One distro test is fine. The other distro maintainers can tweak it as >> necessary. The use of distro build options is also preferred: where >> possible (and reasonable) distro-specific behaviors should be separated >> out into the distro_* build options. > >>> - One module I'm working on (Skype) has shown me that Skype likes reading >>> things in the users' mozilla/firefox files (~/.mozilla/.../sec8.db and >>> prefs.js), most likely to check if the Skype plugin is installed. I >>> personally would not want to have this allowed, but I can imagine that the >>> reference policy doesn't want to prevent activities that are normal >>> behavior. Is that correct? > >> It depends on why this is happening. If you have clicked a link in a >> Skype IM chat and firefox is running in the wrong domain (in skype_t or >> whatever), then we definitely want to fix that, not add access for >> skype_t. If Skype is just accessing the files, then justification for >> the access would need to be provided, since on the surface it looks like >> inappropriate access. > >>> - How much in-line documentation would reference policy suggestions have? >>> Does it make sense to document (as comments) reasons why certain >>> interfaces are called in the .te description? I noticed that not that many >>> modules have much comments beyond the structural separation (to split the >>> policy in related blocks)? > >> We're happy to have additional documentation, as long as its useful, and >> most of all, correct. Obviously comments like this would not be useful: > >> # do dns lookups >> sysnet_dns_name_resolve(my_app_t) > >>> - If an application really requires a permission to be granted (say execmem) >>> but a more global boolean exists (allow_execmem) does reference policy >>> want the module to honor the boolean, or should this only be when both >>> states of the boolean still offer (some) functionality (like allow_dmesg)? > >> If the app intrinsically requires execmem, then just allow it >> unconditionally. An example is java. If you want to use java app, you >> have to accept the risk of having execmem. > >> The conditionals/tunables follow the logic of the code. In your >> allow_dmesg example, its up to the admin to decide if users can run >> dmesg. It won't break user domains if they can't dmesg. So it makes >> sense to have this security-relevant decision exposed in the policy via >> a tunable. > > _______________________________________________ refpolicy mailing list refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy If we only had a write policy that does an isa. A third option would be to write the policy using attributes, with the basics of what a web browser is, web_browser_domain, and then define types for the contents. Then you could say something like type mozilla_t, web_browser_domain; allow mozilla_t .... Or type $1_mozilla_t, web_browser_domain; ... And both use cases are happy. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk0vYp8ACgkQrlYvE4MpobP2WgCdEfeIm8w0w46TQ4/VbSenrZHI wtsAn0PjNK+pk5vSYuWdfNhFLR8Lua5r =P6+W -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-13 20:30 ` Dominick Grift 2011-01-13 20:37 ` Daniel J Walsh @ 2011-01-15 21:03 ` Sven Vermeulen 2011-01-17 14:44 ` Christopher J. PeBenito 1 sibling, 1 reply; 10+ messages in thread From: Sven Vermeulen @ 2011-01-15 21:03 UTC (permalink / raw) To: refpolicy On Thu, Jan 13, 2011 at 09:30:19PM +0100, Dominick Grift wrote: > My opinion on this is different and the mozilla example is a good > example as to why my opinion is different. > > My opinion is that it is preferred to use the per role template with the > role prefixes, as this does not hurt and it offers flexibility for cases > that may not have been foreseen. > > Like mozilla, in refpolicy mozilla is not prefixed. For this reason i > had to redo mozilla policy in my policy that is built on reference > policy. I think refpolicy should be as general as possible. With that i > mean it should be usable whichever way you want to go with you > customized policy. > > Back to mozilla, i have confined thunderbird as well. As you may know > thunderbird can run firefox (click a URL in a mail messages) and firefox > can run thunderbird (send link..) > > So firefox needs to transition to thunderbird and vice versa. But in a > confined user space you will may want to want different firefox policy > depending on who runs it. Therefore you need to prefix the firefox and > thunderbird domains. > > examples: > > user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t > staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t > > This is why i prefer the prefix domains. It does not hurt to use them > and who knows, you may need it later (and my experience says that many > user apps are able to run other agents) > > my two cents What I'm thinking about was how domains can influence each other. Most application domains (like mozilla_t) have some permissions for feedback (such as sigchld/signull sending, fd usage, ...) towards the "caller" domain. I would expect that this is quite harmless, but I can imagine that a well-versed malicious person is able to "influence" a more privileged domain through this. Let me explain with the following example: a staff_u mapped user runs by default in the staff_t domain and launches firefox (transitioning to mozilla_t). He also (in a different terminal) switches role to sysadm_r to perform some administrative tasks. Now, permission-wise, the policy allows the same privileges from mozilla_t to sysadm_t and staff_t. In my imagination, I would see a malicious user influencing the running firefox through whatever exploit available and having the permissions to manipulate some aspects within the sysadm_t domain. Not much and far fetched most likely, but I leave that to the experts in the field. +---------+ +-----------+ | staff_t |<------------>| mozilla_t | +---------+ +-----------+ ^ | +----------+ | | sysadm_t |<-----------------/ +----------+ When using the templates, there would be no SELinux permission whatsoever from the prefixed mozilla domain to the sysadm_t domain: +---------+ +-----------------+ | staff_t |<------------->| staff_mozilla_t | +---------+ +-----------------+ +----------+ | sysadm_t | +----------+ Of course, not allowing sysadm_t to use mozilla will also achieve the same result, but by using templates it seems like this is a bit more under control. The largest impact I see is that this creates most of the rules in the interfaces, requiring a base rebuild for each update (whereas updates in the .te file can be done through module updates without affecting base), but I'm not sure what this "impact" means on manageability and such. At least, I haven't gotten any issues on this for the time being. Wkr, Sven Vermeulen ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-15 21:03 ` Sven Vermeulen @ 2011-01-17 14:44 ` Christopher J. PeBenito 2011-01-17 15:07 ` Dominick Grift 0 siblings, 1 reply; 10+ messages in thread From: Christopher J. PeBenito @ 2011-01-17 14:44 UTC (permalink / raw) To: refpolicy On 1/15/2011 4:03 PM, Sven Vermeulen wrote: > On Thu, Jan 13, 2011 at 09:30:19PM +0100, Dominick Grift wrote: >> My opinion on this is different and the mozilla example is a good >> example as to why my opinion is different. >> >> My opinion is that it is preferred to use the per role template with the >> role prefixes, as this does not hurt and it offers flexibility for cases >> that may not have been foreseen. >> >> Like mozilla, in refpolicy mozilla is not prefixed. For this reason i >> had to redo mozilla policy in my policy that is built on reference >> policy. I think refpolicy should be as general as possible. With that i >> mean it should be usable whichever way you want to go with you >> customized policy. >> >> Back to mozilla, i have confined thunderbird as well. As you may know >> thunderbird can run firefox (click a URL in a mail messages) and firefox >> can run thunderbird (send link..) >> >> So firefox needs to transition to thunderbird and vice versa. But in a >> confined user space you will may want to want different firefox policy >> depending on who runs it. Therefore you need to prefix the firefox and >> thunderbird domains. >> >> examples: >> >> user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t >> staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t >> >> This is why i prefer the prefix domains. It does not hurt to use them >> and who knows, you may need it later (and my experience says that many >> user apps are able to run other agents) >> >> my two cents > > What I'm thinking about was how domains can influence each other. Most > application domains (like mozilla_t) have some permissions for feedback > (such as sigchld/signull sending, fd usage, ...) towards the "caller" > domain. I would expect that this is quite harmless, but I can imagine that > a well-versed malicious person is able to "influence" a more privileged > domain through this. > > Let me explain with the following example: a staff_u mapped user runs by > default in the staff_t domain and launches firefox (transitioning to > mozilla_t). He also (in a different terminal) switches role to sysadm_r to > perform some administrative tasks. > > Now, permission-wise, the policy allows the same privileges from mozilla_t > to sysadm_t and staff_t. In my imagination, I would see a malicious user > influencing the running firefox through whatever exploit available and > having the permissions to manipulate some aspects within the sysadm_t > domain. Not much and far fetched most likely, but I leave that to the > experts in the field. > > +---------+ +-----------+ > | staff_t |<------------>| mozilla_t | > +---------+ +-----------+ > ^ > | > +----------+ | > | sysadm_t |<-----------------/ > +----------+ > > When using the templates, there would be no SELinux permission whatsoever > from the prefixed mozilla domain to the sysadm_t domain: > > +---------+ +-----------------+ > | staff_t |<------------->| staff_mozilla_t | > +---------+ +-----------------+ This is how it used to be; the role was encoded in the types. It was decided that this slim reduction of flexibility was worth the huge reduction of complexity in the policy. Originally we wanted to use the existing SELinux RBAC functionality to keep a true role-based separation. However, that required kernel modifications since labeling objects with a role other than object_r doesn't work completely right (e.g. creating files). We decided to go with UBAC since in systems that actually use multiple roles seriously, and really care about this, already have a 1:1 user:role mapping. I would still like to get the true RBAC separation done, but someone needs to find some time to fix the kernel. You can look in the archives back in 2008 to see more discussion about all of this. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-17 14:44 ` Christopher J. PeBenito @ 2011-01-17 15:07 ` Dominick Grift 2011-01-17 19:17 ` Christopher J. PeBenito 0 siblings, 1 reply; 10+ messages in thread From: Dominick Grift @ 2011-01-17 15:07 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/17/2011 03:44 PM, Christopher J. PeBenito wrote: > On 1/15/2011 4:03 PM, Sven Vermeulen wrote: >> On Thu, Jan 13, 2011 at 09:30:19PM +0100, Dominick Grift wrote: >>> My opinion on this is different and the mozilla example is a good >>> example as to why my opinion is different. >>> >>> My opinion is that it is preferred to use the per role template with the >>> role prefixes, as this does not hurt and it offers flexibility for cases >>> that may not have been foreseen. >>> >>> Like mozilla, in refpolicy mozilla is not prefixed. For this reason i >>> had to redo mozilla policy in my policy that is built on reference >>> policy. I think refpolicy should be as general as possible. With that i >>> mean it should be usable whichever way you want to go with you >>> customized policy. >>> >>> Back to mozilla, i have confined thunderbird as well. As you may know >>> thunderbird can run firefox (click a URL in a mail messages) and firefox >>> can run thunderbird (send link..) >>> >>> So firefox needs to transition to thunderbird and vice versa. But in a >>> confined user space you will may want to want different firefox policy >>> depending on who runs it. Therefore you need to prefix the firefox and >>> thunderbird domains. >>> >>> examples: >>> >>> user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t >>> staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t >>> >>> This is why i prefer the prefix domains. It does not hurt to use them >>> and who knows, you may need it later (and my experience says that many >>> user apps are able to run other agents) >>> >>> my two cents >> >> What I'm thinking about was how domains can influence each other. Most >> application domains (like mozilla_t) have some permissions for feedback >> (such as sigchld/signull sending, fd usage, ...) towards the "caller" >> domain. I would expect that this is quite harmless, but I can imagine that >> a well-versed malicious person is able to "influence" a more privileged >> domain through this. >> >> Let me explain with the following example: a staff_u mapped user runs by >> default in the staff_t domain and launches firefox (transitioning to >> mozilla_t). He also (in a different terminal) switches role to sysadm_r to >> perform some administrative tasks. >> >> Now, permission-wise, the policy allows the same privileges from mozilla_t >> to sysadm_t and staff_t. In my imagination, I would see a malicious user >> influencing the running firefox through whatever exploit available and >> having the permissions to manipulate some aspects within the sysadm_t >> domain. Not much and far fetched most likely, but I leave that to the >> experts in the field. >> >> +---------+ +-----------+ >> | staff_t |<------------>| mozilla_t | >> +---------+ +-----------+ >> ^ >> | >> +----------+ | >> | sysadm_t |<-----------------/ >> +----------+ >> >> When using the templates, there would be no SELinux permission whatsoever >> from the prefixed mozilla domain to the sysadm_t domain: >> >> +---------+ +-----------------+ >> | staff_t |<------------->| staff_mozilla_t | >> +---------+ +-----------------+ > > This is how it used to be; the role was encoded in the types. It was > decided that this slim reduction of flexibility was worth the huge > reduction of complexity in the policy. As i recall it this was more aimed towards derived object types, and not so much derived domain types. I remember dwalsh had issue with prefixed object types because it was not scalable. where on one system you are staff_t and another user_t (mounted home directories/nis etc) I do not see how that applies to domain types. I do agree that derived domain types add flexibility/complexity but i do not see how rbac can replace some of the functionality that prefixed domains and type enforcement provides (e.g. enforce policy for a application based on who runs the application (role prefix) Any gui user application should be prefixed in my view because they can all be run from nautilus and or gpanel (launchers). And if you confine either gpanel or nautilus there is no way to tell selinux who runs the application (other then nautilus or gpanel), and we cannot make any distinction. On top of that the prefixed type gives me the flexibility to create prefixed booleans. It allows me to customize a userdomain by just toggling a few booleans. currently for me role prefixes for domain types proves to be invaluable in my pursuit to confine the user space. > Originally we wanted to use the existing SELinux RBAC functionality to > keep a true role-based separation. However, that required kernel > modifications since labeling objects with a role other than object_r > doesn't work completely right (e.g. creating files). We decided to go > with UBAC since in systems that actually use multiple roles seriously, > and really care about this, already have a 1:1 user:role mapping. > > I would still like to get the true RBAC separation done, but someone > needs to find some time to fix the kernel. > > You can look in the archives back in 2008 to see more discussion about > all of this. > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk00WywACgkQMlxVo39jgT+B5gCgwg6P/ddkrgG7MeLbmX77N0uI QVIAoKTgvMgRY3xNiVsdgdpvP5EaoNTz =XxGU -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-17 15:07 ` Dominick Grift @ 2011-01-17 19:17 ` Christopher J. PeBenito 2011-01-17 19:39 ` Dominick Grift 0 siblings, 1 reply; 10+ messages in thread From: Christopher J. PeBenito @ 2011-01-17 19:17 UTC (permalink / raw) To: refpolicy On 1/17/2011 10:07 AM, Dominick Grift wrote: > On 01/17/2011 03:44 PM, Christopher J. PeBenito wrote: >> On 1/15/2011 4:03 PM, Sven Vermeulen wrote: >>> On Thu, Jan 13, 2011 at 09:30:19PM +0100, Dominick Grift wrote: >>>> My opinion on this is different and the mozilla example is a good >>>> example as to why my opinion is different. >>>> >>>> My opinion is that it is preferred to use the per role template with the >>>> role prefixes, as this does not hurt and it offers flexibility for cases >>>> that may not have been foreseen. >>>> >>>> Like mozilla, in refpolicy mozilla is not prefixed. For this reason i >>>> had to redo mozilla policy in my policy that is built on reference >>>> policy. I think refpolicy should be as general as possible. With that i >>>> mean it should be usable whichever way you want to go with you >>>> customized policy. >>>> >>>> Back to mozilla, i have confined thunderbird as well. As you may know >>>> thunderbird can run firefox (click a URL in a mail messages) and firefox >>>> can run thunderbird (send link..) >>>> >>>> So firefox needs to transition to thunderbird and vice versa. But in a >>>> confined user space you will may want to want different firefox policy >>>> depending on who runs it. Therefore you need to prefix the firefox and >>>> thunderbird domains. >>>> >>>> examples: >>>> >>>> user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t >>>> staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t >>>> >>>> This is why i prefer the prefix domains. It does not hurt to use them >>>> and who knows, you may need it later (and my experience says that many >>>> user apps are able to run other agents) >>>> >>>> my two cents >>> >>> What I'm thinking about was how domains can influence each other. Most >>> application domains (like mozilla_t) have some permissions for feedback >>> (such as sigchld/signull sending, fd usage, ...) towards the "caller" >>> domain. I would expect that this is quite harmless, but I can imagine that >>> a well-versed malicious person is able to "influence" a more privileged >>> domain through this. >>> >>> Let me explain with the following example: a staff_u mapped user runs by >>> default in the staff_t domain and launches firefox (transitioning to >>> mozilla_t). He also (in a different terminal) switches role to sysadm_r to >>> perform some administrative tasks. >>> >>> Now, permission-wise, the policy allows the same privileges from mozilla_t >>> to sysadm_t and staff_t. In my imagination, I would see a malicious user >>> influencing the running firefox through whatever exploit available and >>> having the permissions to manipulate some aspects within the sysadm_t >>> domain. Not much and far fetched most likely, but I leave that to the >>> experts in the field. >>> >>> +---------+ +-----------+ >>> | staff_t |<------------>| mozilla_t | >>> +---------+ +-----------+ >>> ^ >>> | >>> +----------+ | >>> | sysadm_t |<-----------------/ >>> +----------+ >>> >>> When using the templates, there would be no SELinux permission whatsoever >>> from the prefixed mozilla domain to the sysadm_t domain: >>> >>> +---------+ +-----------------+ >>> | staff_t |<------------->| staff_mozilla_t | >>> +---------+ +-----------------+ >> >> This is how it used to be; the role was encoded in the types. It was >> decided that this slim reduction of flexibility was worth the huge >> reduction of complexity in the policy. > > As i recall it this was more aimed towards derived object types, and not > so much derived domain types. No. It was aimed at _all_ role-derived types. > I do agree that derived domain types add flexibility/complexity but i do > not see how rbac can replace some of the functionality that prefixed > domains and type enforcement provides (e.g. enforce policy for a > application based on who runs the application (role prefix) Of course it can't replace all possible uses, but it does replace all upstream instances, save the ones where there are execution path issues like su, sudo, and screen. For example, the mozilla policy was exactly the same for all roles, except each only accessed the role-specific home dir, X window, etc. If all objects in the system have an appropriate role in their context, each instance of mozilla can be cleanly separated by role. > Any gui user application should be prefixed in my view because they can > all be run from nautilus and or gpanel (launchers). And if you confine > either gpanel or nautilus there is no way to tell selinux who runs the > application (other then nautilus or gpanel), and we cannot make any > distinction. > > On top of that the prefixed type gives me the flexibility to create > prefixed booleans. It allows me to customize a userdomain by just > toggling a few booleans. > > currently for me role prefixes for domain types proves to be invaluable > in my pursuit to confine the user space. Of course people can still do this for their custom policies. However, upstream is pragmatic with its usage. The actual security gains by the complexity you suggest tends to be dubious. As long as that is the case, we'll chose simpler policy. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-17 19:17 ` Christopher J. PeBenito @ 2011-01-17 19:39 ` Dominick Grift 2011-01-17 20:28 ` Christopher J. PeBenito 0 siblings, 1 reply; 10+ messages in thread From: Dominick Grift @ 2011-01-17 19:39 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 01/17/2011 08:17 PM, Christopher J. PeBenito wrote: > On 1/17/2011 10:07 AM, Dominick Grift wrote: >> On 01/17/2011 03:44 PM, Christopher J. PeBenito wrote: >>> On 1/15/2011 4:03 PM, Sven Vermeulen wrote: >>>> On Thu, Jan 13, 2011 at 09:30:19PM +0100, Dominick Grift wrote: >>>>> My opinion on this is different and the mozilla example is a good >>>>> example as to why my opinion is different. >>>>> >>>>> My opinion is that it is preferred to use the per role template >>>>> with the >>>>> role prefixes, as this does not hurt and it offers flexibility for >>>>> cases >>>>> that may not have been foreseen. >>>>> >>>>> Like mozilla, in refpolicy mozilla is not prefixed. For this reason i >>>>> had to redo mozilla policy in my policy that is built on reference >>>>> policy. I think refpolicy should be as general as possible. With >>>>> that i >>>>> mean it should be usable whichever way you want to go with you >>>>> customized policy. >>>>> >>>>> Back to mozilla, i have confined thunderbird as well. As you may know >>>>> thunderbird can run firefox (click a URL in a mail messages) and >>>>> firefox >>>>> can run thunderbird (send link..) >>>>> >>>>> So firefox needs to transition to thunderbird and vice versa. But in a >>>>> confined user space you will may want to want different firefox policy >>>>> depending on who runs it. Therefore you need to prefix the firefox and >>>>> thunderbird domains. >>>>> >>>>> examples: >>>>> >>>>> user_mozilla_t -> thunderbird_exec_t -> user_thunderbird_t >>>>> staff_thunderbird_t -> mozilla_exec_t -> staff_mozilla_t >>>>> >>>>> This is why i prefer the prefix domains. It does not hurt to use them >>>>> and who knows, you may need it later (and my experience says that many >>>>> user apps are able to run other agents) >>>>> >>>>> my two cents >>>> >>>> What I'm thinking about was how domains can influence each other. Most >>>> application domains (like mozilla_t) have some permissions for feedback >>>> (such as sigchld/signull sending, fd usage, ...) towards the "caller" >>>> domain. I would expect that this is quite harmless, but I can >>>> imagine that >>>> a well-versed malicious person is able to "influence" a more privileged >>>> domain through this. >>>> >>>> Let me explain with the following example: a staff_u mapped user >>>> runs by >>>> default in the staff_t domain and launches firefox (transitioning to >>>> mozilla_t). He also (in a different terminal) switches role to >>>> sysadm_r to >>>> perform some administrative tasks. >>>> >>>> Now, permission-wise, the policy allows the same privileges from >>>> mozilla_t >>>> to sysadm_t and staff_t. In my imagination, I would see a malicious >>>> user >>>> influencing the running firefox through whatever exploit available and >>>> having the permissions to manipulate some aspects within the sysadm_t >>>> domain. Not much and far fetched most likely, but I leave that to the >>>> experts in the field. >>>> >>>> +---------+ +-----------+ >>>> | staff_t |<------------>| mozilla_t | >>>> +---------+ +-----------+ >>>> ^ >>>> | >>>> +----------+ | >>>> | sysadm_t |<-----------------/ >>>> +----------+ >>>> >>>> When using the templates, there would be no SELinux permission >>>> whatsoever >>>> from the prefixed mozilla domain to the sysadm_t domain: >>>> >>>> +---------+ +-----------------+ >>>> | staff_t |<------------->| staff_mozilla_t | >>>> +---------+ +-----------------+ >>> >>> This is how it used to be; the role was encoded in the types. It was >>> decided that this slim reduction of flexibility was worth the huge >>> reduction of complexity in the policy. >> >> As i recall it this was more aimed towards derived object types, and not >> so much derived domain types. > > No. It was aimed at _all_ role-derived types. > >> I do agree that derived domain types add flexibility/complexity but i do >> not see how rbac can replace some of the functionality that prefixed >> domains and type enforcement provides (e.g. enforce policy for a >> application based on who runs the application (role prefix) > > Of course it can't replace all possible uses, but it does replace all > upstream instances, save the ones where there are execution path issues > like su, sudo, and screen. > > For example, the mozilla policy was exactly the same for all roles, > except each only accessed the role-specific home dir, X window, etc. If > all objects in the system have an appropriate role in their context, > each instance of mozilla can be cleanly separated by role. think of all the nice use cases you can have with prefixed domains like secmark and many other use cases. staff_mozilla_t can use firefox to send recv external packets user_mozilla_t can use firefox to only send recv internal packets. staff_mozilla_t can run plugins user_mozilla_t cannot run plugins etc etc. remember the mozilla_$1... boolean we had? >> Any gui user application should be prefixed in my view because they can >> all be run from nautilus and or gpanel (launchers). And if you confine >> either gpanel or nautilus there is no way to tell selinux who runs the >> application (other then nautilus or gpanel), and we cannot make any >> distinction. >> >> On top of that the prefixed type gives me the flexibility to create >> prefixed booleans. It allows me to customize a userdomain by just >> toggling a few booleans. >> >> currently for me role prefixes for domain types proves to be invaluable >> in my pursuit to confine the user space. > > Of course people can still do this for their custom policies. However, > upstream is pragmatic with its usage. The actual security gains by the > complexity you suggest tends to be dubious. As long as that is the > case, we'll chose simpler policy. > In my view, upstream should in this case probably ignore/exclude user applications all together, no offence. Either she facilitates user space confinement or she does not, no dead ends or false hope for integrity on the desktop. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.16 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ iEYEARECAAYFAk00mvUACgkQMlxVo39jgT93qQCdHPzeyGGAgDTw5fsygBdxjPpB 7iUAn1xmNV33a++wU4q/ozj+zwOqMNt1 =SOIR -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 10+ messages in thread
* [refpolicy] Policy modules design guidelines? 2011-01-17 19:39 ` Dominick Grift @ 2011-01-17 20:28 ` Christopher J. PeBenito 0 siblings, 0 replies; 10+ messages in thread From: Christopher J. PeBenito @ 2011-01-17 20:28 UTC (permalink / raw) To: refpolicy On 1/17/2011 2:39 PM, Dominick Grift wrote: > On 01/17/2011 08:17 PM, Christopher J. PeBenito wrote: >> On 1/17/2011 10:07 AM, Dominick Grift wrote: >>> I do agree that derived domain types add flexibility/complexity but i do >>> not see how rbac can replace some of the functionality that prefixed >>> domains and type enforcement provides (e.g. enforce policy for a >>> application based on who runs the application (role prefix) >> >> Of course it can't replace all possible uses, but it does replace all >> upstream instances, save the ones where there are execution path issues >> like su, sudo, and screen. >> >> For example, the mozilla policy was exactly the same for all roles, >> except each only accessed the role-specific home dir, X window, etc. If >> all objects in the system have an appropriate role in their context, >> each instance of mozilla can be cleanly separated by role. > > think of all the nice use cases you can have with prefixed domains > like secmark and many other use cases. > > staff_mozilla_t can use firefox to send recv external packets > user_mozilla_t can use firefox to only send recv internal packets. > > staff_mozilla_t can run plugins > user_mozilla_t cannot run plugins > > etc etc. > > remember the mozilla_$1... boolean we had? As I have said before, it was a trade off. It was discussed and what we have is the result of the decision. I'm sorry it does not match your goals perfectly. >>> Any gui user application should be prefixed in my view because they can >>> all be run from nautilus and or gpanel (launchers). And if you confine >>> either gpanel or nautilus there is no way to tell selinux who runs the >>> application (other then nautilus or gpanel), and we cannot make any >>> distinction. >>> >>> On top of that the prefixed type gives me the flexibility to create >>> prefixed booleans. It allows me to customize a userdomain by just >>> toggling a few booleans. >>> >>> currently for me role prefixes for domain types proves to be invaluable >>> in my pursuit to confine the user space. >> >> Of course people can still do this for their custom policies. However, >> upstream is pragmatic with its usage. The actual security gains by the >> complexity you suggest tends to be dubious. As long as that is the >> case, we'll chose simpler policy. >> > > In my view, upstream should in this case probably ignore/exclude user > applications all together, no offence. Either she facilitates user space > confinement or she does not, no dead ends or false hope for integrity on > the desktop. That is a black-or-white logical fallacy. Upstream IS facilitating confinement. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-01-17 20:28 UTC | newest] Thread overview: 10+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-01-12 20:46 [refpolicy] Policy modules design guidelines? Sven Vermeulen 2011-01-13 19:52 ` Christopher J. PeBenito 2011-01-13 20:30 ` Dominick Grift 2011-01-13 20:37 ` Daniel J Walsh 2011-01-15 21:03 ` Sven Vermeulen 2011-01-17 14:44 ` Christopher J. PeBenito 2011-01-17 15:07 ` Dominick Grift 2011-01-17 19:17 ` Christopher J. PeBenito 2011-01-17 19:39 ` Dominick Grift 2011-01-17 20:28 ` Christopher J. PeBenito
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.