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
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
http://www.tresys.com | oss.tresys.com
-----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-----
-----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-----
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
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
http://www.tresys.com | oss.tresys.com
-----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-----
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
http://www.tresys.com | oss.tresys.com
-----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-----
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
http://www.tresys.com | oss.tresys.com