[refpolicy] Restricting access to pcscd socket

[refpolicy] Restricting access to pcscd socket

[Luis Ressel]

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

[refpolicy] [PATCH 1/3] Add a boolean governing mozilla plugin access to pcscd.

[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

[refpolicy] [PATCH 2/3] Add a boolean governing xguest access to pcscd.

[Luis Ressel]

---
 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

[refpolicy] [PATCH 3/3] Add a boolean governing kerberos access to pcscd.

[Luis Ressel]

---
 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

[refpolicy] [PATCH 1/3] Add a boolean governing mozilla plugin access to pcscd.

[Sven Vermeulen]

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" <aranea@aixah.de> 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 

[refpolicy] Restricting access to pcscd socket

[Christopher J. PeBenito]

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

[refpolicy] Restricting access to pcscd socket

[Luis Ressel]

On Sat, 15 Feb 2014 15:36:16 -0500
"Christopher J. PeBenito" <cpebenito@tresys.com> 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 

[refpolicy] Restricting access to pcscd socket

[Luis Ressel]

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 

[refpolicy] Restricting access to pcscd socket

[Christopher J. PeBenito]

On 2/15/2014 4:00 PM, Luis Ressel wrote:
> On Sat, 15 Feb 2014 15:36:16 -0500
> "Christopher J. PeBenito" <cpebenito@tresys.com> 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
www.tresys.com | oss.tresys.com