The policy grants the right to access the pcscd socket (PC/SC daemon, a daemon
for accessing smartcards) to some domains which rarely need it: xguest_t,
mozilla_plugin_t and kerberos users (through kerberos_use()). While there are
use cases which require this access, most do not, and access to a smartcard is
something rather critical. Therefore I propose to make this permission a
tunable.
There are some other domains which are granted this access (openct_t,
certmonger_t, certwatch_t, and after my last patch also gpg_agent_t), but they
are specifically crypto-related and should be well-protected, so I decided to
leave their permissions unconditional. (Sure, kerberos is also crypto-related,
but in that policy, the right is granted to any application using kerberos, not
only a separate process.)
What do you think?
Regards,
Luis Ressel
---
mozilla.te | 13 +++++++++++--
1 file changed, 11 insertions(+), 2 deletions(-)
diff --git a/mozilla.te b/mozilla.te
index 11ac8e4..fe67bc9 100644
--- a/mozilla.te
+++ b/mozilla.te
@@ -1,4 +1,4 @@
-policy_module(mozilla, 2.8.0)
+policy_module(mozilla, 2.8.1)
########################################
#
@@ -13,6 +13,13 @@ policy_module(mozilla, 2.8.0)
## </desc>
gen_tunable(mozilla_execstack, false)
+## <desc>
+## <p>
+## Allow mozilla plugins to connect to pcscd
+## </p>
+## </desc>
+gen_tunable(mozilla_connect_pcscd, false)
+
attribute_role mozilla_roles;
attribute_role mozilla_plugin_roles;
attribute_role mozilla_plugin_config_roles;
@@ -556,7 +563,9 @@ optional_policy(`
')
optional_policy(`
- pcscd_stream_connect(mozilla_plugin_t)
+ tunable_policy(`mozilla_connect_pcscd',`
+ pcscd_stream_connect(mozilla_plugin_t)
+ ')
')
optional_policy(`
--
1.8.5.4
---
kerberos.if | 4 +++-
kerberos.te | 9 ++++++++-
2 files changed, 11 insertions(+), 2 deletions(-)
diff --git a/kerberos.if b/kerberos.if
index f6c00d8..2d72456 100644
--- a/kerberos.if
+++ b/kerberos.if
@@ -108,7 +108,9 @@ interface(`kerberos_use',`
optional_policy(`
tunable_policy(`allow_kerberos',`
- pcscd_stream_connect($1)
+ tunable_policy(`kerberos_connect_pcscd',`
+ pcscd_stream_connect($1)
+ ')
')
')
diff --git a/kerberos.te b/kerberos.te
index 8833d59..eee29ca 100644
--- a/kerberos.te
+++ b/kerberos.te
@@ -1,4 +1,4 @@
-policy_module(kerberos, 1.12.0)
+policy_module(kerberos, 1.12.1)
########################################
#
@@ -12,6 +12,13 @@ policy_module(kerberos, 1.12.0)
## </desc>
gen_tunable(allow_kerberos, false)
+## <desc>
+## <p>
+## Determine whether kerberos can connect to pcscd.
+## </p>
+## </desc>
+gen_tunable(kerberos_connect_pcscd, false)
+
type kadmind_t;
type kadmind_exec_t;
init_daemon_domain(kadmind_t, kadmind_exec_t)
--
1.8.5.4
---
xguest.te | 16 +++++++++++++---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/xguest.te b/xguest.te
index a64aad3..527a13b 100644
--- a/xguest.te
+++ b/xguest.te
@@ -1,4 +1,4 @@
-policy_module(xguest, 1.2.0)
+policy_module(xguest, 1.2.1)
########################################
#
@@ -24,6 +24,14 @@ gen_tunable(xguest_connect_network, false)
## <desc>
## <p>
## Determine whether xguest can
+## connect to pcscd.
+## </p>
+## </desc>
+gen_tunable(xguest_connect_pcscd, false)
+
+## <desc>
+## <p>
+## Determine whether xguest can
## use blue tooth devices.
## </p>
## </desc>
@@ -164,8 +172,10 @@ optional_policy(`
')
optional_policy(`
- pcscd_read_pid_files(xguest_t)
- pcscd_stream_connect(xguest_t)
+ tunable_policy(`xguest_connect_pcscd',`
+ pcscd_read_pid_files(xguest_t)
+ pcscd_stream_connect(xguest_t)
+ ')
')
#gen_user(xguest_u,, xguest_r, s0, s0)
--
1.8.5.4
Try not to bump the module versions with patches as those would immediately
collide if another patch is staged simultaneously.
Wkr,
Sven
On Feb 14, 2014 8:47 PM, "Luis Ressel" <[email protected]> wrote:
> ---
> mozilla.te | 13 +++++++++++--
> 1 file changed, 11 insertions(+), 2 deletions(-)
>
> diff --git a/mozilla.te b/mozilla.te
> index 11ac8e4..fe67bc9 100644
> --- a/mozilla.te
> +++ b/mozilla.te
> @@ -1,4 +1,4 @@
> -policy_module(mozilla, 2.8.0)
> +policy_module(mozilla, 2.8.1)
>
> ########################################
> #
> @@ -13,6 +13,13 @@ policy_module(mozilla, 2.8.0)
> ## </desc>
> gen_tunable(mozilla_execstack, false)
>
> +## <desc>
> +## <p>
> +## Allow mozilla plugins to connect to pcscd
> +## </p>
> +## </desc>
> +gen_tunable(mozilla_connect_pcscd, false)
> +
> attribute_role mozilla_roles;
> attribute_role mozilla_plugin_roles;
> attribute_role mozilla_plugin_config_roles;
> @@ -556,7 +563,9 @@ optional_policy(`
> ')
>
> optional_policy(`
> - pcscd_stream_connect(mozilla_plugin_t)
> + tunable_policy(`mozilla_connect_pcscd',`
> + pcscd_stream_connect(mozilla_plugin_t)
> + ')
> ')
>
> optional_policy(`
> --
> 1.8.5.4
>
> _______________________________________________
> refpolicy mailing list
> refpolicy at oss.tresys.com
> http://oss.tresys.com/mailman/listinfo/refpolicy
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://oss.tresys.com/pipermail/refpolicy/attachments/20140214/ce2b2bcc/attachment.html
On 2/14/2014 2:47 PM, Luis Ressel wrote:
> The policy grants the right to access the pcscd socket (PC/SC daemon, a daemon
> for accessing smartcards) to some domains which rarely need it: xguest_t,
> mozilla_plugin_t and kerberos users (through kerberos_use()). While there are
> use cases which require this access, most do not, and access to a smartcard is
> something rather critical. Therefore I propose to make this permission a
> tunable.
>
> There are some other domains which are granted this access (openct_t,
> certmonger_t, certwatch_t, and after my last patch also gpg_agent_t), but they
> are specifically crypto-related and should be well-protected, so I decided to
> leave their permissions unconditional. (Sure, kerberos is also crypto-related,
> but in that policy, the right is granted to any application using kerberos, not
> only a separate process.)
>
> What do you think?
Typically I would take something like this. Conditionally making the policy stricter is usually a good thing. I'm not so sure that it makes sense here. It doesn't seem like it buys much.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com
On Sat, 15 Feb 2014 15:36:16 -0500
"Christopher J. PeBenito" <[email protected]> wrote:
> Typically I would take something like this. Conditionally making the
> policy stricter is usually a good thing. I'm not so sure that it
> makes sense here. It doesn't seem like it buys much.
>
I'm not sure about either. If I understand it correctly, once one
application accesses a smartcard, it gets exclusive access - other
applications can't access it anymore until the using application stops
using the smartcard (and hopefully resets it before).
On the other hand, something as security-critical as a smartcard daemon
should be well-protected, and mozilla_plugin_t is a really exposed
domain. Same goes for xguest_t - you expect that one to have minimal
permissions, and that normally wouldn't include access to smartcards.
Therefore, I think it would be a good idea to add these booleans. Could
you perhaps elaborate a bit on them "not buying much"?
Regards,
Luis Ressel
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 966 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140215/439d0445/attachment.bin
Ping?
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20140811/680bc2a1/attachment.bin
On 2/15/2014 4:00 PM, Luis Ressel wrote:
> On Sat, 15 Feb 2014 15:36:16 -0500
> "Christopher J. PeBenito" <[email protected]> wrote:
>
>> Typically I would take something like this. Conditionally making the
>> policy stricter is usually a good thing. I'm not so sure that it
>> makes sense here. It doesn't seem like it buys much.
>
> I'm not sure about either. If I understand it correctly, once one
> application accesses a smartcard, it gets exclusive access - other
> applications can't access it anymore until the using application stops
> using the smartcard (and hopefully resets it before).
>
> On the other hand, something as security-critical as a smartcard daemon
> should be well-protected, and mozilla_plugin_t is a really exposed
> domain. Same goes for xguest_t - you expect that one to have minimal
> permissions, and that normally wouldn't include access to smartcards.
>
> Therefore, I think it would be a good idea to add these booleans. Could
> you perhaps elaborate a bit on them "not buying much"?
The ability to check passwords suffers the same problem but we don't
make the chkpwd rules conditional.
--
Chris PeBenito
Tresys Technology, LLC
http://www.tresys.com | oss.tresys.com