From: guido@trentalancia.net (Guido Trentalancia)
Date: Tue, 06 Sep 2016 01:10:10 +0200
Subject: [refpolicy] [PATCH 2/2] evolution: add support for the new user
 certificates
In-Reply-To: <4d32e35b-fa61-95b4-d8a9-8eef2a9e3d22@ieee.org>
References: <1472911622.3372.2.camel@trentalancia.net>
	<1472911720.3372.4.camel@trentalancia.net>
	<4d32e35b-fa61-95b4-d8a9-8eef2a9e3d22@ieee.org>
Message-ID: <1473117010.17491.2.camel@trentalancia.net>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello Christopher.

My reply follows the quoted text...

On Mon, 05/09/2016 at 10.20 -0400, Chris PeBenito wrote:
> On 09/03/16 10:08, Guido Trentalancia via refpolicy wrote:
> > 
> > Update the evolution module so that it is able to create, read and
> > write
> > the newly created user certificates files and directories
> > (user_cert_t).
> > 
> > Signed-off-by: Guido Trentalancia <guido@trentalancia.net>
> > ---
> > ?policy/modules/contrib/evolution.te |????2 ++
> > ?1 file changed, 2 insertions(+)
> > 
> > --- refpolicy-git-14082016-orig-
> > evolution/policy/modules/contrib/evolution.te	2016-09-03
> > 15:51:41.893570747 +0200
> > +++ refpolicy-git-14082016-user-certs-
> > evolution/policy/modules/contrib/evolution.te	2016-09-03
> > 15:52:43.680488794 +0200
> > @@ -178,6 +178,7 @@ auth_use_nsswitch(evolution_t)
> > 
> > ?logging_send_syslog_msg(evolution_t)
> > 
> > +miscfiles_manage_user_cert(evolution_t)
> > ?miscfiles_read_generic_certs(evolution_t)
> > ?miscfiles_read_localization(evolution_t)
> > 
> > @@ -432,6 +433,7 @@ fs_search_auto_mountpoints(evolution_ser
> > 
> > ?auth_use_nsswitch(evolution_server_t)
> > 
> > +miscfiles_manage_user_cert(evolution_server_t)
> > ?miscfiles_read_localization(evolution_server_t)
> > ?miscfiles_read_generic_certs(evolution_server_t)
> 
> One question I have is, do we want to make this access conditional??
> Since the certificates are not specific to evolution, perhaps users
> may?
> not want evolution to access them???Maybe read only access is a
> third?
> alternative?
> 
> i.e. conditionals to achieve these options:
> 1. manage access
> 2. read-only access
> 3. no access
> 
> is something to consider.

I am not sure about this, especially forbidding the access completely.

The use of digital certificates is now part of every fully-featured
mail client application.

The point is that either the user trusts evolution as a mail client
application or not.

If evolution is a trusted application, then there is no reason to limit
its ability to access the user certificates.

On the other hand, if the user doesn't trust evolution, he/she can just
use another application and that is the end of the story.

Finally, I believe that an effective policy should not include too many
booleans, otherwise there is an high risk that it becomes too difficult
to use and that's not what we want.

I have created a new version (v2) of this patch (attached to the next
message) that only switches the read/write operation on user
certificates, thus adding some configurability value, without being
excessively difficult to use.

I hope you agree with me...

Best regards,

Guido