From: domg472@gmail.com (Dominick Grift) Date: Mon, 24 Jan 2011 22:22:56 +0100 Subject: [refpolicy] [PATCH/RFC 0/19]: patch set to update the git reference policy In-Reply-To: <1295902888.31686.24.camel@tesla.lan> 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> <1295902888.31686.24.camel@tesla.lan> Message-ID: <4D3DEDB0.3060101@gmail.com> To: refpolicy@oss.tresys.com List-Id: refpolicy.oss.tresys.com -----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-----