* [refpolicy] state of core/contrib split @ 2012-09-06 17:01 Christopher J. PeBenito 2012-09-06 17:15 ` Guido Trentalancia 0 siblings, 1 reply; 12+ messages in thread From: Christopher J. PeBenito @ 2012-09-06 17:01 UTC (permalink / raw) To: refpolicy The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? Additionally, due to his many contributions to the policy and reviewing of others' patches, Dominick Grift has been given contrib commit access. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-06 17:01 [refpolicy] state of core/contrib split Christopher J. PeBenito @ 2012-09-06 17:15 ` Guido Trentalancia 2012-09-06 18:03 ` Dominick Grift ` (2 more replies) 0 siblings, 3 replies; 12+ messages in thread From: Guido Trentalancia @ 2012-09-06 17:15 UTC (permalink / raw) To: refpolicy On 06/09/2012 19:01, Christopher J. PeBenito wrote: > The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? In my opinion, file contexts are probably impossible (or at least extremely expensive) to tackle in a one-fits-all way for all possible distributions and at the same time they are sort of silly blockers. > Additionally, due to his many contributions to the policy and reviewing of others' patches, Dominick Grift has been given contrib commit access. > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-06 17:15 ` Guido Trentalancia @ 2012-09-06 18:03 ` Dominick Grift 2012-09-06 18:45 ` Miroslav Grepl 2012-09-07 11:00 ` Guido Trentalancia 2012-09-07 12:48 ` Russell Coker 2 siblings, 1 reply; 12+ messages in thread From: Dominick Grift @ 2012-09-06 18:03 UTC (permalink / raw) To: refpolicy On Thu, 2012-09-06 at 19:15 +0200, Guido Trentalancia wrote: > On 06/09/2012 19:01, Christopher J. PeBenito wrote: > > The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? > > In my opinion, file contexts are probably impossible (or at least > extremely expensive) to tackle in a one-fits-all way for all possible > distributions and at the same time they are sort of silly blockers. > > > Additionally, due to his many contributions to the policy and reviewing of others' patches, Dominick Grift has been given contrib commit access. > > I just made my first commit which was a trivial one and symbolic. Porting some of the fedora policy is harder than one might think. One issue is that it may require changes to refpolicy (not contrib) others have to do with how fedora deals with certain issues ( which are probably not acceptable by refpolicy ) One thing Fedora could do in my opinion is when it makes commits to its own git repository, take some time to see if this commit applies or is easily applied to contrib/refpolicy. That probably means keeping a local refpolicy/contrib policy and port the commits to that and then either submit the patches to this list or commit to refpolicy/contrib them selves. That requires extra work no doubt but maybe Miroslav and his employer are willing to take that extra effort in order to make the changes not bigger than they already are. Some changes refpolicy should not want as it sets a bad precedent IMHO. I have seen this. The last week i have been trying to write a systemd policy on top of refpolicy on a minimal fedora 18 system and i encountered issue that i would not have if i would write my systemd policy on to of fedora policy. This is due to some coarse rules added to fedora that hide/obscure some important issues that ideally need to be confronted head on. For example: dealing with inheriting and fd In the refpolicy we have the opportunity to not go the same route as fedora. (In some regard refpolicy also went astray in my opinion though , for example i suspect refpolicy made/makes domains unconfined to easily) That means that some changes, and their dependencies, downstream just cant apply to refpolicy. So its a tough situation that we probably only can resolve together i suspect. It requires that we agree on standards/rules and share the same values. Prefer quality over quantity, but i guess its also give and take on both sides of the isle. Some frank and open communication can go a long way, but i understand for many its a paid job with dead lines and stuff. So its not easy. I will do what i can to merge as much to contrib as i can as long as i can. I don't deal with employers and deadlines so much but i have my share of uncertainty that i have to deal with in my life. I like the split of refpolicy and contrib. unfortunately refpolicy does not build without contrib though due to optional policy i guess. It is also unfortunate that eclipse-slide is no longer in active development. This application really make life much easier and productive for policy writers > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-06 18:03 ` Dominick Grift @ 2012-09-06 18:45 ` Miroslav Grepl 2012-09-06 18:55 ` Daniel J Walsh 0 siblings, 1 reply; 12+ messages in thread From: Miroslav Grepl @ 2012-09-06 18:45 UTC (permalink / raw) To: refpolicy On 09/06/2012 08:03 PM, Dominick Grift wrote: > > On Thu, 2012-09-06 at 19:15 +0200, Guido Trentalancia wrote: >> On 06/09/2012 19:01, Christopher J. PeBenito wrote: >>> The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? >> In my opinion, file contexts are probably impossible (or at least >> extremely expensive) to tackle in a one-fits-all way for all possible >> distributions and at the same time they are sort of silly blockers. >> >>> Additionally, due to his many contributions to the policy and reviewing of others' patches, Dominick Grift has been given contrib commit access. >>> > I just made my first commit which was a trivial one and symbolic. > Porting some of the fedora policy is harder than one might think. One > issue is that it may require changes to refpolicy (not contrib) others > have to do with how fedora deals with certain issues ( which are > probably not acceptable by refpolicy ) > > One thing Fedora could do in my opinion is when it makes commits to its > own git repository, take some time to see if this commit applies or is > easily applied to contrib/refpolicy. > > That probably means keeping a local refpolicy/contrib policy and port > the commits to that and then either submit the patches to this list or > commit to refpolicy/contrib them selves. > > That requires extra work no doubt but maybe Miroslav and his employer > are willing to take that extra effort in order to make the changes not > bigger than they already are. > > Some changes refpolicy should not want as it sets a bad precedent IMHO. > I have seen this. > > The last week i have been trying to write a systemd policy on top of > refpolicy on a minimal fedora 18 system and i encountered issue that i > would not have if i would write my systemd policy on to of fedora > policy. > > This is due to some coarse rules added to fedora that hide/obscure some > important issues that ideally need to be confronted head on. > > For example: dealing with inheriting and fd > > In the refpolicy we have the opportunity to not go the same route as > fedora. (In some regard refpolicy also went astray in my opinion > though , for example i suspect refpolicy made/makes domains unconfined > to easily) That means that some changes, and their dependencies, > downstream just cant apply to refpolicy. > > So its a tough situation that we probably only can resolve together i > suspect. It requires that we agree on standards/rules and share the same > values. Prefer quality over quantity, but i guess its also give and take > on both sides of the isle. > > Some frank and open communication can go a long way, but i understand > for many its a paid job with dead lines and stuff. > > So its not easy. > > I will do what i can to merge as much to contrib as i can as long as i > can. I don't deal with employers and deadlines so much but i have my > share of uncertainty that i have to deal with in my life. > > I like the split of refpolicy and contrib. unfortunately refpolicy does > not build without contrib though due to optional policy i guess. > > It is also unfortunate that eclipse-slide is no longer in active > development. This application really make life much easier and > productive for policy writers We have changed our structure to reflect upstream structure recently. And I believe it will be easier to accept Fedora changes now (which I tried some time ago and it was accepted). Now this is my goal to prepare good patches which could be applied. > > >> _______________________________________________ >> refpolicy mailing list >> refpolicy at oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy > > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-06 18:45 ` Miroslav Grepl @ 2012-09-06 18:55 ` Daniel J Walsh 2012-09-06 19:21 ` Dominick Grift 0 siblings, 1 reply; 12+ messages in thread From: Daniel J Walsh @ 2012-09-06 18:55 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/06/2012 02:45 PM, Miroslav Grepl wrote: > On 09/06/2012 08:03 PM, Dominick Grift wrote: >> >> On Thu, 2012-09-06 at 19:15 +0200, Guido Trentalancia wrote: >>> On 06/09/2012 19:01, Christopher J. PeBenito wrote: >>>> The core/contrib split in the refpolicy repo has been around for a >>>> year. Unfortunately, I don't think it has gone as originally >>>> planned, as the people with commit access haven't really been >>>> committing anything. Differences between refpolicy and distro >>>> policies are pretty severe in some cases. What can we do to improve >>>> the situation? >>> In my opinion, file contexts are probably impossible (or at least >>> extremely expensive) to tackle in a one-fits-all way for all possible >>> distributions and at the same time they are sort of silly blockers. >>> >>>> Additionally, due to his many contributions to the policy and >>>> reviewing of others' patches, Dominick Grift has been given contrib >>>> commit access. >>>> >> I just made my first commit which was a trivial one and symbolic. Porting >> some of the fedora policy is harder than one might think. One issue is >> that it may require changes to refpolicy (not contrib) others have to do >> with how fedora deals with certain issues ( which are probably not >> acceptable by refpolicy ) >> >> One thing Fedora could do in my opinion is when it makes commits to its >> own git repository, take some time to see if this commit applies or is >> easily applied to contrib/refpolicy. >> >> That probably means keeping a local refpolicy/contrib policy and port the >> commits to that and then either submit the patches to this list or commit >> to refpolicy/contrib them selves. >> >> That requires extra work no doubt but maybe Miroslav and his employer are >> willing to take that extra effort in order to make the changes not bigger >> than they already are. >> >> Some changes refpolicy should not want as it sets a bad precedent IMHO. I >> have seen this. >> >> The last week i have been trying to write a systemd policy on top of >> refpolicy on a minimal fedora 18 system and i encountered issue that i >> would not have if i would write my systemd policy on to of fedora >> policy. >> >> This is due to some coarse rules added to fedora that hide/obscure some >> important issues that ideally need to be confronted head on. >> >> For example: dealing with inheriting and fd >> >> In the refpolicy we have the opportunity to not go the same route as >> fedora. (In some regard refpolicy also went astray in my opinion though , >> for example i suspect refpolicy made/makes domains unconfined to easily) >> That means that some changes, and their dependencies, downstream just >> cant apply to refpolicy. >> >> So its a tough situation that we probably only can resolve together i >> suspect. It requires that we agree on standards/rules and share the same >> values. Prefer quality over quantity, but i guess its also give and take >> on both sides of the isle. >> >> Some frank and open communication can go a long way, but i understand for >> many its a paid job with dead lines and stuff. >> >> So its not easy. >> >> I will do what i can to merge as much to contrib as i can as long as i >> can. I don't deal with employers and deadlines so much but i have my >> share of uncertainty that i have to deal with in my life. >> >> I like the split of refpolicy and contrib. unfortunately refpolicy does >> not build without contrib though due to optional policy i guess. >> >> It is also unfortunate that eclipse-slide is no longer in active >> development. This application really make life much easier and productive >> for policy writers > We have changed our structure to reflect upstream structure recently. And I > believe it will be easier to accept Fedora changes now (which I tried some > time ago and it was accepted). Now this is my goal to prepare good patches > which could be applied. > >> >> >>> _______________________________________________ refpolicy mailing list >>> refpolicy at oss.tresys.com >>> http://oss.tresys.com/mailman/listinfo/refpolicy >> >> _______________________________________________ refpolicy mailing list >> refpolicy at oss.tresys.com >> http://oss.tresys.com/mailman/listinfo/refpolicy > > _______________________________________________ refpolicy mailing list > refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy > The problem I saw when I started to merge changes in the past was that lots of new policies required changes to the base, especially corenetwork. As miroslav said, he has split out the policy to match upstream, so testing it against the upstream base might get a little easier. Having additional people like Dominick helping to merge would be great, since we never seem to have the time. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBI8Z4ACgkQrlYvE4MpobOPlwCfZhQOKLjV2qxaptB2KkjCkm55 dAkAoOBPa+uI31HPebW4/gLzAYysk3Rl =PTHn -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-06 18:55 ` Daniel J Walsh @ 2012-09-06 19:21 ` Dominick Grift 0 siblings, 0 replies; 12+ messages in thread From: Dominick Grift @ 2012-09-06 19:21 UTC (permalink / raw) To: refpolicy On Thu, 2012-09-06 at 14:55 -0400, Daniel J Walsh wrote: > > The problem I saw when I started to merge changes in the past was that lots of > new policies required changes to the base, especially corenetwork. As The issue with regard to port labeling should in my view be easily solved. just label the darned ports :) so if we can just merge corenetwork.te.in ( atleast with regard to declaring new port types.) then that should give me more room to merge stuff. although i really like your idea of using attributes to classify ports rather than giving them a service specific name. But there are more issues but it does not have to be perfect in my view. If fedora has something controversial then, in my view, i could just merge the policy without the controversial bits (if i cant fix it to something acceptable myself). Policy is never perfect anyways is always a process. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-06 17:15 ` Guido Trentalancia 2012-09-06 18:03 ` Dominick Grift @ 2012-09-07 11:00 ` Guido Trentalancia 2012-09-07 11:22 ` Daniel J Walsh 2012-09-07 12:24 ` Christopher J. PeBenito 2012-09-07 12:48 ` Russell Coker 2 siblings, 2 replies; 12+ messages in thread From: Guido Trentalancia @ 2012-09-07 11:00 UTC (permalink / raw) To: refpolicy On 06/09/2012 19:15, Guido Trentalancia wrote: > On 06/09/2012 19:01, Christopher J. PeBenito wrote: >> The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? > > In my opinion, file contexts are probably impossible (or at least > extremely expensive) to tackle in a one-fits-all way for all possible > distributions and at the same time they are sort of silly blockers. In addition to the above, simple patches sometimes don't get through. Take for example, the cpucontrol module patch that I recently posted. It just ended up in nothing without sufficient follow-up. I am not trying to blame anyone in particular and for sufficient follow-up, I do simply mean that, in my opinion, there needs to be at least three kinds of tagging following the post of a patch: NEEDS_REWORK (patch is interesting and could be possibly applied with minor or major rework), MERGED (patch is applied straight), REJECTED_NO_FOLLOW_UP (patch is trying to gear current policy in a direction that is not acceptable/profitable and therefore it is not going to be supported). I have not received any of the above replies for some patches (including the cpucontrol module one), therefore I do not know how to proceed. There were problems with file-contexts, this is always going to happen to a certain extent until distributions interested in supporting SELinux will make a list of their file locations easily accessible from the web or ftp (e.g. http://www.distro1.org/filelist.txt, ftp://ftp.distro1.org/filelist.txt, ftp://ftp.distro2.org/filelist.txt). But apart from that it is entirely unknown to me whether it is worth or not keep working on that... It shouldn't be expensive for distributions to publish their latest file locations. It will allow SELinux policy developers to create policy based upon the latest location of their distributed binaries (because they often change suddenly and often tend to vary too much amongst different distributions, not necessarily with a consequent profit). Otherwise, the work-load on the policy developer might become too high. Other patches also got stuck in SELinux userspace. Most notably, one patch that aimed at re-stabilizing (read fixing a bug) policycoreutils/semanage ([PATCH v2]: seobject.py must skip comments while reading external configuration files, Aug 2012 and optionally [PATCH]: libselinux: improve the file_contexts.5 manual page, Aug 2012) after changes made to the policy ([refpolicy] [PATCH v1/v2]: clarify the file_contexts.subs_dist configuration file usage, Aug 2012). >> Additionally, due to his many contributions to the policy and reviewing of others' patches, Dominick Grift has been given contrib commit access. ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-07 11:00 ` Guido Trentalancia @ 2012-09-07 11:22 ` Daniel J Walsh 2012-09-07 12:24 ` Christopher J. PeBenito 1 sibling, 0 replies; 12+ messages in thread From: Daniel J Walsh @ 2012-09-07 11:22 UTC (permalink / raw) To: refpolicy -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 09/07/2012 07:00 AM, Guido Trentalancia wrote: > On 06/09/2012 19:15, Guido Trentalancia wrote: >> On 06/09/2012 19:01, Christopher J. PeBenito wrote: >>> The core/contrib split in the refpolicy repo has been around for a >>> year. Unfortunately, I don't think it has gone as originally planned, >>> as the people with commit access haven't really been committing >>> anything. Differences between refpolicy and distro policies are pretty >>> severe in some cases. What can we do to improve the situation? >> >> In my opinion, file contexts are probably impossible (or at least >> extremely expensive) to tackle in a one-fits-all way for all possible >> distributions and at the same time they are sort of silly blockers. > > In addition to the above, simple patches sometimes don't get through. > > Take for example, the cpucontrol module patch that I recently posted. It > just ended up in nothing without sufficient follow-up. > > I am not trying to blame anyone in particular and for sufficient follow-up, > I do simply mean that, in my opinion, there needs to be at least three > kinds of tagging following the post of a patch: NEEDS_REWORK (patch is > interesting and could be possibly applied with minor or major rework), > MERGED (patch is applied straight), REJECTED_NO_FOLLOW_UP (patch is trying > to gear current policy in a direction that is not acceptable/profitable and > therefore it is not going to be supported). > Obviously if your patch is in Fedora, we give it an implicit ACK. > I have not received any of the above replies for some patches (including > the cpucontrol module one), therefore I do not know how to proceed. There > were problems with file-contexts, this is always going to happen to a > certain extent until distributions interested in supporting SELinux will > make a list of their file locations easily accessible from the web or ftp > (e.g. http://www.distro1.org/filelist.txt, > ftp://ftp.distro1.org/filelist.txt, ftp://ftp.distro2.org/filelist.txt). > But apart from that it is entirely unknown to me whether it is worth or not > keep working on that... > > It shouldn't be expensive for distributions to publish their latest file > locations. It will allow SELinux policy developers to create policy based > upon the latest location of their distributed binaries (because they often > change suddenly and often tend to vary too much amongst different > distributions, not necessarily with a consequent profit). Otherwise, the > work-load on the policy developer might become too high. > > Other patches also got stuck in SELinux userspace. Most notably, one patch > that aimed at re-stabilizing (read fixing a bug) policycoreutils/semanage > ([PATCH v2]: seobject.py must skip comments while reading external > configuration files, Aug 2012 and optionally [PATCH]: libselinux: improve > the file_contexts.5 manual page, Aug 2012) after changes made to the policy > ([refpolicy] [PATCH v1/v2]: clarify the file_contexts.subs_dist > configuration file usage, Aug 2012). > >>> Additionally, due to his many contributions to the policy and reviewing >>> of others' patches, Dominick Grift has been given contrib commit >>> access. > > _______________________________________________ refpolicy mailing list > refpolicy at oss.tresys.com http://oss.tresys.com/mailman/listinfo/refpolicy > SELinux userspace should be brought up on the selinux list. Eric is getting preparing a push, but has been held up because of linuxcon. If you do not see your patch in his push, I would ping him. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlBJ2QwACgkQrlYvE4MpobPhYQCgk4kB2Zp60HooTgOQuLi/BAzg mVUAn1X2XWOo7hqoLLs4jAiuRSjGfQdm =P6sN -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-07 11:00 ` Guido Trentalancia 2012-09-07 11:22 ` Daniel J Walsh @ 2012-09-07 12:24 ` Christopher J. PeBenito 2012-09-07 12:51 ` Guido Trentalancia 1 sibling, 1 reply; 12+ messages in thread From: Christopher J. PeBenito @ 2012-09-07 12:24 UTC (permalink / raw) To: refpolicy On 09/07/12 07:00, Guido Trentalancia wrote: > On 06/09/2012 19:15, Guido Trentalancia wrote: >> On 06/09/2012 19:01, Christopher J. PeBenito wrote: >>> The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? >> >> In my opinion, file contexts are probably impossible (or at least >> extremely expensive) to tackle in a one-fits-all way for all possible >> distributions and at the same time they are sort of silly blockers. > > In addition to the above, simple patches sometimes don't get through. > > Take for example, the cpucontrol module patch that I recently posted. It > just ended up in nothing without sufficient follow-up. I'm not sure why you're saying this about cpucontrol. From what I can see in my emails, I gave you feedback, and you said you would be making a new version, but I haven't seen any new patches. -- Chris PeBenito Tresys Technology, LLC www.tresys.com | oss.tresys.com ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-07 12:24 ` Christopher J. PeBenito @ 2012-09-07 12:51 ` Guido Trentalancia 2012-09-07 13:25 ` Guido Trentalancia 0 siblings, 1 reply; 12+ messages in thread From: Guido Trentalancia @ 2012-09-07 12:51 UTC (permalink / raw) To: refpolicy On 07/09/2012 14:24, Christopher J. PeBenito wrote: > On 09/07/12 07:00, Guido Trentalancia wrote: >> On 06/09/2012 19:15, Guido Trentalancia wrote: >>> On 06/09/2012 19:01, Christopher J. PeBenito wrote: >>>> The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? >>> >>> In my opinion, file contexts are probably impossible (or at least >>> extremely expensive) to tackle in a one-fits-all way for all possible >>> distributions and at the same time they are sort of silly blockers. >> >> In addition to the above, simple patches sometimes don't get through. >> >> Take for example, the cpucontrol module patch that I recently posted. It >> just ended up in nothing without sufficient follow-up. > > I'm not sure why you're saying this about cpucontrol. From what I can see in my emails, I gave you feedback, and you said you would be making a new version, but I haven't seen any new patches. I can easily make a new version. But licensing issues on a wide range of deployed systems is something I prefer not to deal with. In my opinion, hardware vendors should not impose licensing restrictions that are much more restrictive than forbidding the use of their products for building or trafficking weapons or conducting illegal practices (which is of course is rather generic as in general it depends on local and sometimes also international jurisdiction). The rest of the licensing should probably happen in software. And this opens the door to another opportunity: as SELinux introduced TE (possibly a trademark), the policy should probably introduce a maximum software-licensing acceptable level (e.g. GPLv1, GPLv2, GPLv3 and so on). As far as I know, at the moment, on most or all distributions it is not possible for the user to impose a restriction such as: "I do not want to expose my machine to any other licence than GPLv3", for example, by easily configuring a simple centralized system-wide configuration file that cannot be modified by others. Kind regards, Guido ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-07 12:51 ` Guido Trentalancia @ 2012-09-07 13:25 ` Guido Trentalancia 0 siblings, 0 replies; 12+ messages in thread From: Guido Trentalancia @ 2012-09-07 13:25 UTC (permalink / raw) To: refpolicy On 07/09/2012 14:51, Guido Trentalancia wrote: > On 07/09/2012 14:24, Christopher J. PeBenito wrote: >> On 09/07/12 07:00, Guido Trentalancia wrote: >>> On 06/09/2012 19:15, Guido Trentalancia wrote: >>>> On 06/09/2012 19:01, Christopher J. PeBenito wrote: >>>>> The core/contrib split in the refpolicy repo has been around for a year. Unfortunately, I don't think it has gone as originally planned, as the people with commit access haven't really been committing anything. Differences between refpolicy and distro policies are pretty severe in some cases. What can we do to improve the situation? >>>> >>>> In my opinion, file contexts are probably impossible (or at least >>>> extremely expensive) to tackle in a one-fits-all way for all possible >>>> distributions and at the same time they are sort of silly blockers. >>> >>> In addition to the above, simple patches sometimes don't get through. >>> >>> Take for example, the cpucontrol module patch that I recently posted. It >>> just ended up in nothing without sufficient follow-up. >> >> I'm not sure why you're saying this about cpucontrol. From what I can see in my emails, I gave you feedback, and you said you would be making a new version, but I haven't seen any new patches. > > I can easily make a new version. But licensing issues on a wide range of > deployed systems is something I prefer not to deal with. > > In my opinion, hardware vendors should not impose licensing restrictions > that are much more restrictive than forbidding the use of their products > for building or trafficking weapons or conducting illegal practices > (which is of course is rather generic as in general it depends on local > and sometimes also international jurisdiction). And, of course, if it is not open-hardware as applicable to the case at hand, protecting their intellectual property. But, it shouldn't be transitioning so easily as for a few mouse clicks from basically no-license to a situation which is so restrictive and still quite ambiguous to me such as "personal non-commercial". > The rest of the licensing should probably happen in software. And this > opens the door to another opportunity: as SELinux introduced TE > (possibly a trademark), the policy should probably introduce a maximum > software-licensing acceptable level (e.g. GPLv1, GPLv2, GPLv3 and so on). > > As far as I know, at the moment, on most or all distributions it is not > possible for the user to impose a restriction such as: "I do not want to > expose my machine to any other licence than GPLv3", for example, by > easily configuring a simple centralized system-wide configuration file > that cannot be modified by others. > > Kind regards, > > Guido > _______________________________________________ > refpolicy mailing list > refpolicy at oss.tresys.com > http://oss.tresys.com/mailman/listinfo/refpolicy > ^ permalink raw reply [flat|nested] 12+ messages in thread
* [refpolicy] state of core/contrib split 2012-09-06 17:15 ` Guido Trentalancia 2012-09-06 18:03 ` Dominick Grift 2012-09-07 11:00 ` Guido Trentalancia @ 2012-09-07 12:48 ` Russell Coker 2 siblings, 0 replies; 12+ messages in thread From: Russell Coker @ 2012-09-07 12:48 UTC (permalink / raw) To: refpolicy On Fri, 7 Sep 2012, Guido Trentalancia <guido@trentalancia.com> wrote: > In my opinion, file contexts are probably impossible (or at least > extremely expensive) to tackle in a one-fits-all way for all possible > distributions and at the same time they are sort of silly blockers. The ifdef(`distro_whatever' blocks are good for that. It's usually not too difficult to determine what label to apply to a file if you know the label that is used on another distribution. While file names are different they usually aren't that different. In most cases it's a matter of directory names. http://ftp.debian.org/debian/dists/wheezy/ It would be really handy to have a list of file locations used for all the major distributions, for reference the above is the canonical place for such information about Debian/Wheezy, see the Contents-$ARCH.gz files. Also go up a directory to find the lists for other versions of Debian. Maybe we should have a section of the wiki about developing policy which lists all the locations for lists of file names. -- My Main Blog http://etbe.coker.com.au/ My Documents Blog http://doc.coker.com.au/ ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2012-09-07 13:25 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2012-09-06 17:01 [refpolicy] state of core/contrib split Christopher J. PeBenito 2012-09-06 17:15 ` Guido Trentalancia 2012-09-06 18:03 ` Dominick Grift 2012-09-06 18:45 ` Miroslav Grepl 2012-09-06 18:55 ` Daniel J Walsh 2012-09-06 19:21 ` Dominick Grift 2012-09-07 11:00 ` Guido Trentalancia 2012-09-07 11:22 ` Daniel J Walsh 2012-09-07 12:24 ` Christopher J. PeBenito 2012-09-07 12:51 ` Guido Trentalancia 2012-09-07 13:25 ` Guido Trentalancia 2012-09-07 12:48 ` Russell Coker
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.