From: guido@trentalancia.com (Guido Trentalancia)
Date: Mon, 24 Jan 2011 22:01:28 +0100
Subject: [refpolicy] [PATCH/RFC 0/19]: patch set to update the git
 reference policy
In-Reply-To: <4D3DA1F3.7010705@gmail.com>
References: <1295397630.3377.10.camel@tesla.lan> <4D383627.60804@tresys.com>
	<1295544776.4702.16.camel@tesla.lan> <4D397E26.4090904@tresys.com>
	<1295829820.3862.59.camel@tesla.lan>  <4D3D9456.60608@gmail.com>
	<1295884566.1547.13.camel@tesla.lan>  <4D3DA1F3.7010705@gmail.com>
Message-ID: <1295902888.31686.24.camel@tesla.lan>
To: refpolicy@oss.tresys.com
List-Id: refpolicy.oss.tresys.com

Hello Dominick,

thanks for your reply !

On Mon, 24/01/2011 at 16.59 +0100, Dominick Grift wrote:
> On 01/24/2011 04:56 PM, Guido Trentalancia wrote:
> >> I did a quick review of your policy and commented inline. I think most
> >> of it is probably not acceptable at this point unfortunately.
> > 
> > Yes, I have started to look at your comments. Of course they are all
> > good points that you have made and that need to be changed.
> > 
> > But after those issues will have been fixed, what else would prevent the
> > patch from being committed ?
> 
> For example the way you deal with dbus chat, is not the way refpolicy
> usually deas with it.

Yes, I know.

> Where you have dbus_*_send interfaces that only go one way, refpolicy
> uses dbus_*_chat interfaces that are bi-directional.
> 
> This is because if some process send a message and is allowed that, then
> one can be sure that the receiving party will want to reply to that
> message and that you will want to allow that reply (why else would you
> have allowed the initial party to send a message in the first place?

This is one thing I definitely not agree with. The way it's implemented
in the patch is better in my opinion. It is more flexible and it is more
in line with the aims of a reference policy.

One should not assume anything. Permissions to send_msg should be given
to each module separately only for what concerns that module (and not
the other party which might eventually be involved in a "chat"). A chat
is a concept too advanced for a reference policy. The policy should just
grant permissions for a module to send out something. It should not even
know that a "chat" is having place.

Of course, this is my point of view. If it necessarily needs to be the
other way to get committed, it can still be changed but I would
certainly do things differently on my side.

There are many changes that you propose. Apart from this latest one
(which is somewhat also mentioned in [2/19]), I am in perfect agreement
with what you say (well, to be honest I still need to look more
carefully at the feasibility of [5/19], [6/19], [8/19] and [13/19] but
there shouldn't be any problem as long as it is feasible).
Because there are many changes to carry out, I would prepare new patches
only if it is then worth committing them... Nobody else has commented
anything. I still think it's really worth applying these changes to the
reference policy (or otherwise it seems that basic functionality of a
generic system is not being guaranteed) !

I would really need to know before I proceed...

Regards,

Guido