[refpolicy] [PATCH/RFC 0/19]: patch set to update the git reference policy

[domg472@gmail.com (Dominick Grift)]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/24/2011 10:01 PM, Guido Trentalancia wrote:
> 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.

Well, i am not sure about it. Security is a trade off between security
and usability. Ask your self does this added complexity of yours really
add valuable security? Are there any cases where one party sends a
message without getting a reply?

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

i am just an humble hobbyist with an opinion. I to would be interested
to hear others (especially people with authority) opinion on it. But
from experience i can tell you that it is almost if not always a chat thing.

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

My advice is that you send small patches for each functionality and
explain why its needed in as much detail as possible. ofcourse you
should make sure you apply style rules and also make sure you compare
your changes with similar policy in refpolicy to see if your change
complies with refpolicy design. (e.g. the decisions refpolicy made with
regard to how particular issue should be handled)

I have proposed many patches to refpolicy. Several had many revision and
eventually were not accepted. It is in my view not easy to maintain an
upstream policy because there are many things to take into account
before you can accept a patch. That also means that the submitter has to
know alot of properties of refpolicy.

Else the maintainer spends all his time reviewing patches and explaining
people about these properties over and over again.

So before you submit, double... triple check your patches.

The first time one submit a patch that has mistakes is not a big deal,
the second time i guess neither. But one sends many patches that keep
having issues and the maintainer has to review them all, then i can
imagine that after a while the maintainer is not so eager anymore to
review it...

So the point of all this is. Best to spend a little more time getting
familair with the properties of the policy, and be confident that any
patch you submit has a high chance of getting accepted. So verify style,
properties etc.

This also to save yourself some frustration.

Again, though, i am just an hobbyist. I have no authority and i am just
trying to help.

> I would really need to know before I proceed...
>
> Regards,
> 
> Guido
> 

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.16 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iEYEARECAAYFAk097bAACgkQMlxVo39jgT+LZgCePiXR6U4rWrMR3EDuQKwDLuyz
lEkAniIuzEAbNKP505VgfIEwQ5NoJTWH
=bsId
-----END PGP SIGNATURE-----