Re: GCL and SELinux: help requested
On Thu, Nov 23, 2017 at 10:21 AM, Lukas Vrabecwrote: > On 11/23/2017 10:17 AM, Javier Martinez Canillas wrote: >> >> Hello, >> >> On Fri, Oct 20, 2017 at 2:12 PM, Lukas Vrabec wrote: >> >> [snip] >> >>> >>> Hello community, >>> We, as Red Hat SELinux team, apologise for recent delays with our answers >>> to >>> your requests and questions related to SELinux. We have been quite busy >>> last >>> couple of weeks so we decided to set a lower priority for Fedora work. We >>> already responded and resolved what was needed and we are ready to react >>> more flexibly in the future. >>> >>> Note: If you are interested in writing custom SELinux policy for your >>> package, you can follow the >>> https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation on >>> wiki. >>> >> >> To update the tpm2-abrmd [0] package to the latest version, I need to >> add a SELinux policy due recent upstream changes in the upstream >> project. But after reading the documents referred in this thread, is >> still not clear to me if the preferred method nowadays is to propose >> adding the SELinux policy to the system wide selinux-policy package or >> to ship a custom SELinux security module for the package. >> > > > Hi, > > SELinux policy for this project is already existing? If not I can help you It doesn't exist in Fedora yet, so currently the tpm2-abrmd daemon runs in an unconfined domain. A policy module was added to the project repo [0] though, but I don't know how correct it is (I'm not a SELinux expert). The specific problem is that now the daemon uses sockets to communicate with a library, but the dbus-daemon in the system bus isn't allowed to read/write to sockets created by processes in an unconfined domain. It used pipes before and that was allowed. > with creating policy for this project. From SELinux team it's prefered to No worries, I think I can sort it out using the SELinux policy in the tpm2-abrmd repo as a base. I just asked since wasn't clear to me which approach was preferred. > add policy to your package. Guidelines how to do that is in progress to be > part of rpm packaging guidelines. > Awesome, I'll re-read [1] then and ad d the policy to the package. Thanks a lot for your help! > Lukas. > [0]: https://github.com/intel/tpm2-abrmd/pull/205/commits/3621742344534a5d0d5d255d1d5bc698f3d39a57 [1]: https://fedoraproject.org/wiki/SELinux/IndependentPolicy Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 11/23/2017 10:17 AM, Javier Martinez Canillas wrote: Hello, On Fri, Oct 20, 2017 at 2:12 PM, Lukas Vrabecwrote: [snip] Hello community, We, as Red Hat SELinux team, apologise for recent delays with our answers to your requests and questions related to SELinux. We have been quite busy last couple of weeks so we decided to set a lower priority for Fedora work. We already responded and resolved what was needed and we are ready to react more flexibly in the future. Note: If you are interested in writing custom SELinux policy for your package, you can follow the https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation on wiki. To update the tpm2-abrmd [0] package to the latest version, I need to add a SELinux policy due recent upstream changes in the upstream project. But after reading the documents referred in this thread, is still not clear to me if the preferred method nowadays is to propose adding the SELinux policy to the system wide selinux-policy package or to ship a custom SELinux security module for the package. Hi, SELinux policy for this project is already existing? If not I can help you with creating policy for this project. From SELinux team it's prefered to add policy to your package. Guidelines how to do that is in progress to be part of rpm packaging guidelines. Lukas. Regards, Lukas [0]: https://github.com/intel/tpm2-abrmd Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
Hello, On Fri, Oct 20, 2017 at 2:12 PM, Lukas Vrabecwrote: [snip] > > Hello community, > We, as Red Hat SELinux team, apologise for recent delays with our answers to > your requests and questions related to SELinux. We have been quite busy last > couple of weeks so we decided to set a lower priority for Fedora work. We > already responded and resolved what was needed and we are ready to react > more flexibly in the future. > > Note: If you are interested in writing custom SELinux policy for your > package, you can follow the > https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation on > wiki. > To update the tpm2-abrmd [0] package to the latest version, I need to add a SELinux policy due recent upstream changes in the upstream project. But after reading the documents referred in this thread, is still not clear to me if the preferred method nowadays is to propose adding the SELinux policy to the system wide selinux-policy package or to ship a custom SELinux security module for the package. > Regards, > Lukas > [0]: https://github.com/intel/tpm2-abrmd Best regards, Javier ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Tue, Oct 24, 2017 at 12:25:14PM +0200, Petr Lautrbach wrote: > On Tue, Oct 24, 2017 at 09:10:32AM +0200, Dominik 'Rathann' Mierzejewski > wrote: > > Hello, Lukas. > > Thanks for this thread. > > > > On Monday, 23 October 2017 at 17:50, Lukas Vrabec wrote: > > > On 10/21/2017 08:48 PM, Kevin Fenzi wrote: > > [...] > > > > Also, perhaps it would make sense to move to a more normal looking > > > > release flow instead of a massive patch? I think that might make it > > > > easier to see whats going on and how to contribute. > > > > > > > > > > This "massive" patch is here because, we diverted from Upsteam policy. > > > Because Upstream policy is much more strict, you cannot even boot F26+ > > > just with upstream policy. We confine more services then upstream and > > > we're more benevolent. > > > > The usual way of doing such things is to create a fork from which > > patches can be merged to the original tree. Surely merging one massive > > patch is much more difficult than single commits or even series of > > commits. I assume you do have a fork of the original SELinux policy > > source tree somewhere, so why don't you simply ship a tarball of your > > fork instead of upstream+massive patch? > > From selinux-policy.spec: > >26 # Use the following command to create patch from > https://github.com/fedora-selinux/selinux-policy >27 # git diff eb4512f6eb13792c76ff8d3e6f2df3a7155db577 rawhide > > policy-rawhide-base.patch >28 # Use the following command to create patch from > https://github.com/fedora-selinux/selinux-policy-contrib >29 # git diff 64302b790bf2b39d93610e1452c8361d56966ae0 rawhide > > policy-rawhide-contrib.patch > > So the fork is at https://github.com/fedora-selinux/selinux-policy and > https://github.com/fedora-selinux/selinux-policy-contrib > > There's a document > https://github.com/fedora-selinux/selinux-policy/wiki/HowToContribute > which is as recent as it could be but it gives insight how which is NOT as recent as it could be > does it work. This document should be probably linked directly in spec > file. > > > > > > > > This should change, and we're trying to focus on technical solution > > > which should decrease amount of maintenance of selinux-policy. We'll > > > inform you about this project. > > > > If you shared more details about this effort now, you would be more > > likely to receive help from the community earlier. > > > > > > > Note: If you are interested in writing custom SELinux policy for your > > > > > package, you can follow the > > > > > https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation > > > > > on wiki. > > > > > > > > Perhaps you could submit this to the FPC and get it reviewed and moved > > > > under the normal packaging space? > > > > > > > > > > Will do. > > > > Excellent, thank you! > > > > Regards, > > Dominik > > -- > > Fedora https://getfedora.org | RPMFusion http://rpmfusion.org > > There should be a science of discontent. People need hard times and > > oppression to develop psychic muscles. > > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > > ___ > > devel mailing list -- devel@lists.fedoraproject.org > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Tue, Oct 24, 2017 at 09:10:32AM +0200, Dominik 'Rathann' Mierzejewski wrote: > Hello, Lukas. > Thanks for this thread. > > On Monday, 23 October 2017 at 17:50, Lukas Vrabec wrote: > > On 10/21/2017 08:48 PM, Kevin Fenzi wrote: > [...] > > > Also, perhaps it would make sense to move to a more normal looking > > > release flow instead of a massive patch? I think that might make it > > > easier to see whats going on and how to contribute. > > > > > > > This "massive" patch is here because, we diverted from Upsteam policy. > > Because Upstream policy is much more strict, you cannot even boot F26+ > > just with upstream policy. We confine more services then upstream and > > we're more benevolent. > > The usual way of doing such things is to create a fork from which > patches can be merged to the original tree. Surely merging one massive > patch is much more difficult than single commits or even series of > commits. I assume you do have a fork of the original SELinux policy > source tree somewhere, so why don't you simply ship a tarball of your > fork instead of upstream+massive patch? From selinux-policy.spec: 26 # Use the following command to create patch from https://github.com/fedora-selinux/selinux-policy 27 # git diff eb4512f6eb13792c76ff8d3e6f2df3a7155db577 rawhide > policy-rawhide-base.patch 28 # Use the following command to create patch from https://github.com/fedora-selinux/selinux-policy-contrib 29 # git diff 64302b790bf2b39d93610e1452c8361d56966ae0 rawhide > policy-rawhide-contrib.patch So the fork is at https://github.com/fedora-selinux/selinux-policy and https://github.com/fedora-selinux/selinux-policy-contrib There's a document https://github.com/fedora-selinux/selinux-policy/wiki/HowToContribute which is as recent as it could be but it gives insight how does it work. This document should be probably linked directly in spec file. > > This should change, and we're trying to focus on technical solution > > which should decrease amount of maintenance of selinux-policy. We'll > > inform you about this project. > > If you shared more details about this effort now, you would be more > likely to receive help from the community earlier. > > > > > Note: If you are interested in writing custom SELinux policy for your > > > > package, you can follow the > > > > https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation > > > > on wiki. > > > > > > Perhaps you could submit this to the FPC and get it reviewed and moved > > > under the normal packaging space? > > > > > > > Will do. > > Excellent, thank you! > > Regards, > Dominik > -- > Fedora https://getfedora.org | RPMFusion http://rpmfusion.org > There should be a science of discontent. People need hard times and > oppression to develop psychic muscles. > -- from "Collected Sayings of Muad'Dib" by the Princess Irulan > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
Hello, Lukas. Thanks for this thread. On Monday, 23 October 2017 at 17:50, Lukas Vrabec wrote: > On 10/21/2017 08:48 PM, Kevin Fenzi wrote: [...] > > Also, perhaps it would make sense to move to a more normal looking > > release flow instead of a massive patch? I think that might make it > > easier to see whats going on and how to contribute. > > > > This "massive" patch is here because, we diverted from Upsteam policy. > Because Upstream policy is much more strict, you cannot even boot F26+ > just with upstream policy. We confine more services then upstream and > we're more benevolent. The usual way of doing such things is to create a fork from which patches can be merged to the original tree. Surely merging one massive patch is much more difficult than single commits or even series of commits. I assume you do have a fork of the original SELinux policy source tree somewhere, so why don't you simply ship a tarball of your fork instead of upstream+massive patch? > This should change, and we're trying to focus on technical solution > which should decrease amount of maintenance of selinux-policy. We'll > inform you about this project. If you shared more details about this effort now, you would be more likely to receive help from the community earlier. > > > Note: If you are interested in writing custom SELinux policy for your > > > package, you can follow the > > > https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation > > > on wiki. > > > > Perhaps you could submit this to the FPC and get it reviewed and moved > > under the normal packaging space? > > > > Will do. Excellent, thank you! Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/21/2017 08:48 PM, Kevin Fenzi wrote: On 10/20/2017 05:12 AM, Lukas Vrabec wrote: Hello community, Hey Lukas. Thanks for chiming in here. We, as Red Hat SELinux team, apologise for recent delays with our answers to your requests and questions related to SELinux. We have been quite busy last couple of weeks so we decided to set a lower priority for Fedora work. We already responded and resolved what was needed and we are ready to react more flexibly in the future. Perhaps you could outline the best ways for people to contribute/get attention? bugzilla bugs? github issues? PR's? Also, perhaps it would make sense to move to a more normal looking release flow instead of a massive patch? I think that might make it easier to see whats going on and how to contribute. This "massive" patch is here because, we diverted from Upsteam policy. Because Upstream policy is much more strict, you cannot even boot F26+ just with upstream policy. We confine more services then upstream and we're more benevolent. This should change, and we're trying to focus on technical solution which should decrease amount of maintenance of selinux-policy. We'll inform you about this project. Note: If you are interested in writing custom SELinux policy for your package, you can follow the https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation on wiki. Perhaps you could submit this to the FPC and get it reviewed and moved under the normal packaging space? Will do. Lukas. Thanks again, kevin ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/20/2017 05:12 AM, Lukas Vrabec wrote: > Hello community, Hey Lukas. Thanks for chiming in here. > We, as Red Hat SELinux team, apologise for recent delays with our > answers to your requests and questions related to SELinux. We have been > quite busy last couple of weeks so we decided to set a lower priority > for Fedora work. We already responded and resolved what was needed and > we are ready to react more flexibly in the future. Perhaps you could outline the best ways for people to contribute/get attention? bugzilla bugs? github issues? PR's? Also, perhaps it would make sense to move to a more normal looking release flow instead of a massive patch? I think that might make it easier to see whats going on and how to contribute. > Note: If you are interested in writing custom SELinux policy for your > package, you can follow the > https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation > on wiki. Perhaps you could submit this to the FPC and get it reviewed and moved under the normal packaging space? Thanks again, kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 11:07 PM, Jerry James wrote: On Sat, Oct 7, 2017 at 9:34 AM, Jerry Jameswrote: I don't believe that anybody looks at those pull requests on a regular basis. Should somebody be doing so? There are 8 pull requests, dating back to about the time of the above conversation. Five of those don't contain a single comment. I opened one for gcl on July 29, and added a comment a month later asking if somebody was going to look at it. No response. This is a bit annoying, considering that I opened a bugzilla request asking for the same thing 4 years ago, and no action has ever been taken on it. I thought maybe a PR would finally get something to happen. Nearly a week has gone by, and no answer. I'm really stumped about what to do. Let me summarize the whole long saga and solicit help. GCL is a Common Lisp implementation. It is known for its speed compared to other CL implementations. It has a long lineage, summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I took over maintenance of the package in late 2008 when the previous maintainer did not have time to continue. At that point, the package did not build in Rawhide and was slated to be dropped from Fedora soon. I got it working with help from upstream and Daniel Walsh, who provided advice on putting together an SELinux policy to account for the fact that GCL produces executable code on the fly by calling mprotect on selected pages. Fast forward to 2013. By that time, the GCL policy also had to mention maxima executables, since executables built with GCL also use the GCL memory allocator. I figured that meant it was time to merge the GCL policy into the system policy, and consequently opened a bugzilla ticket. In spite of me trying to reboot the conversation a couple of times, those involved who held the SELinux reins for Fedora, Just. Could. Not. Stay. On. Topic. We talked about the execheap permission in general, and its place in the universe. Some of them sneeringly, condescendingly wondered why upstream and I were both so incompetent that we didn't just rewrite the allocator to use mmap. (Hint: it isn't easy, and upstream isn't interested in the exercise.) After multiple failures on my part to get something to happen, I gave up in despair. Fast forward to 2017. Attempts to build maxima with gcl on aarch64 started hanging at package install time. See https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed on gcl, incorrectly I believe. As I pointed out in the bug, nothing built from gcl sources runs at package install time, so the hang must be happening inside one of fixfiles, semodule, or restorecon, which ARE run from the gcl install scripts because GCL has to install its own SELinux policy, due to that policy not being merged into the system policy. So, policycoreutils maintainers! Something Is Afoot on aarch64! But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. I still want the system policy to account for GCL, in some way or another. But, as you can see from the quoted text above, submitting a pull request to the relevant git repository has resulted in months of . And pointing that out on this list last weekend has resulted in still more of the crickets. So ... what is a packager supposed to do Why is it so hard to get any attention for submissions to the system SELinux policy? There should be a barrier to entry; I understand that. But I can't even get the gatekeeper to have a conversation with me. Hellp!!! Frustratedly yours, Hello community, We, as Red Hat SELinux team, apologise for recent delays with our answers to your requests and questions related to SELinux. We have been quite busy last couple of weeks so we decided to set a lower priority for Fedora work. We already responded and resolved what was needed and we are ready to react more flexibly in the future. Note: If you are interested in writing custom SELinux policy for your package, you can follow the https://fedoraproject.org/wiki/SELinux/IndependentPolicy documentation on wiki. Regards, Lukas -- Lukas Vrabec Software Engineer, Security Technologies Red Hat, Inc. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Mon, Oct 16, 2017 at 12:04:58PM -0700, Japheth Cleaver wrote: > On 10/13/2017 2:41 PM, Richard W.M. Jones wrote: > >On Fri, Oct 13, 2017 at 03:07:05PM -0600, Jerry James wrote: > >>But that's not the end of the fun. GCL failed the mass rebuild this > >>summer. It built successfully on every architecture but s390x. On > >>s390x, the build failed due to a failed call to mprotect(), almost > >>certainly a sign that SELinux was in enforcing mode on the builder. > >>Was that a known issue with s390x builders? And, if so, has it been > >>rectified since? If so, I'll try building again. > >AIUI the builders run with SELinux disabled. Has this changed? > > > >Rich. > > > Is there a particular reason for this? I'd think Permissive would be > a better option, so that any issues can be noted and (potentially) > resolved down the line. Sorry, I meant Permissive (but not Enforcing). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/16/2017 09:04 PM, Japheth Cleaver wrote: On 10/13/2017 2:41 PM, Richard W.M. Jones wrote: On Fri, Oct 13, 2017 at 03:07:05PM -0600, Jerry James wrote: But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. AIUI the builders run with SELinux disabled. Has this changed? Rich. Is there a particular reason for this? I'd think Permissive would be a better option, so that any issues can be noted and (potentially) resolved down the line. I don't think the policy plays nicely with chroots, so you probably wouldn't get any useful data anyway. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 2:41 PM, Richard W.M. Jones wrote: On Fri, Oct 13, 2017 at 03:07:05PM -0600, Jerry James wrote: But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. AIUI the builders run with SELinux disabled. Has this changed? Rich. Is there a particular reason for this? I'd think Permissive would be a better option, so that any issues can be noted and (potentially) resolved down the line. -jc ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
> On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: > > I don't know. Others have expressed frustration with selinux policy > > maintainers of late as well. It's really hard to say what the trouble > > is... are there to few of them? Overtasked with other work? Workflow too > > difficult? Perhaps we can get FESCO or someone to work with them and try > > and come up with a more open and working workflow. I'm not sure what the > > answer is here. I see it's not just me then that's noticed this. It wasn't too long ago that I could file a BZ and see updates later that day. That was unbelievably fast turnaround and made admin life so much easier. I'd rarely bother with a local policy to address such issues because they were generally so temporary. However, I've noticed with, at least BZ#1448877 opened back in May, hasn't seem to have gotten the slightest bit of attention. I try to avoid local policies because I highly doubt that what I arrive at is done as securely as it should be, but more importantly that doesn't help anyone else out who's in or will be in the same situation.___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 14 Oct 2017 12:08 am, "Adam Williamson"wrote: On Fri, 2017-10-13 at 15:58 -0700, Kevin Fenzi wrote: > On 10/13/2017 03:00 PM, Adam Williamson wrote: > > On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: > > > It's really hard to say what the trouble > > > is... are there to few of them? Overtasked with other work? Workflow too > > > difficult? > > > > AFAIK it's basically just lvrabec at the moment, and I think the 'map' > > permission issues that showed up this cycle may have been keeping him > > pretty busy. Not sure if there are other factors involved. > > The workflow is pretty unclear too...at least to me. > > Like there are never any new releases anymore and just large patches > against that release... > > rawhide has 3.13.1-295 ! > and > -rw-rw-r--. 1 kevin kevin 1685866 Oct 13 15:54 policy-rawhide-base.patch > -rw-rw-r--. 1 kevin kevin 3664459 Oct 13 15:54 policy-rawhide-contrib.patch > > If you want to do a PR what do you do here? Yeah, I noticed that too and found it a bit weird, but wasn't sure whether to stick any oars in. Perhaps we could ask Lukas, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org The few selinux policy changes I've needed in the past have been a pull request to the fedora policy on github and a bug filed in bugzilla linking to the PR ... Nothing more complex than that. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Fri, 2017-10-13 at 15:58 -0700, Kevin Fenzi wrote: > On 10/13/2017 03:00 PM, Adam Williamson wrote: > > On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: > > > It's really hard to say what the trouble > > > is... are there to few of them? Overtasked with other work? Workflow too > > > difficult? > > > > AFAIK it's basically just lvrabec at the moment, and I think the 'map' > > permission issues that showed up this cycle may have been keeping him > > pretty busy. Not sure if there are other factors involved. > > The workflow is pretty unclear too...at least to me. > > Like there are never any new releases anymore and just large patches > against that release... > > rawhide has 3.13.1-295 ! > and > -rw-rw-r--. 1 kevin kevin 1685866 Oct 13 15:54 policy-rawhide-base.patch > -rw-rw-r--. 1 kevin kevin 3664459 Oct 13 15:54 policy-rawhide-contrib.patch > > If you want to do a PR what do you do here? Yeah, I noticed that too and found it a bit weird, but wasn't sure whether to stick any oars in. Perhaps we could ask Lukas, though. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 03:00 PM, Adam Williamson wrote: > On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: >> It's really hard to say what the trouble >> is... are there to few of them? Overtasked with other work? Workflow too >> difficult? > > AFAIK it's basically just lvrabec at the moment, and I think the 'map' > permission issues that showed up this cycle may have been keeping him > pretty busy. Not sure if there are other factors involved. The workflow is pretty unclear too...at least to me. Like there are never any new releases anymore and just large patches against that release... rawhide has 3.13.1-295 ! and -rw-rw-r--. 1 kevin kevin 1685866 Oct 13 15:54 policy-rawhide-base.patch -rw-rw-r--. 1 kevin kevin 3664459 Oct 13 15:54 policy-rawhide-contrib.patch If you want to do a PR what do you do here? > It seems like there's sort of been an idea floating around for a while > that we should be trying to move SELinux policies out of the > centralized selinux-policy package - e.g. the Apache-relevant policies > should move into the httpd package, and so on - but I don't know any > details about how serious / achievable that idea is. It *is* possible > for packages to ship their own SELinux policies now, though, and some > (not many) do. Yeah, this idea is already true with epel now. It used to be RHEL selinux folks would add in policy for epel packages, but they now will not and require them to be in the package itself. At least they have said so in bugs, without much in the way of any formal announcement. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Fri, 2017-10-13 at 14:53 -0700, Kevin Fenzi wrote: > It's really hard to say what the trouble > is... are there to few of them? Overtasked with other work? Workflow too > difficult? AFAIK it's basically just lvrabec at the moment, and I think the 'map' permission issues that showed up this cycle may have been keeping him pretty busy. Not sure if there are other factors involved. It seems like there's sort of been an idea floating around for a while that we should be trying to move SELinux policies out of the centralized selinux-policy package - e.g. the Apache-relevant policies should move into the httpd package, and so on - but I don't know any details about how serious / achievable that idea is. It *is* possible for packages to ship their own SELinux policies now, though, and some (not many) do. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 02:07 PM, Jerry James wrote: > On Sat, Oct 7, 2017 at 9:34 AM, Jerry Jameswrote: ...snip... > But that's not the end of the fun. GCL failed the mass rebuild this > summer. It built successfully on every architecture but s390x. On > s390x, the build failed due to a failed call to mprotect(), almost > certainly a sign that SELinux was in enforcing mode on the builder. > Was that a known issue with s390x builders? And, if so, has it been > rectified since? If so, I'll try building again. The default config for all our builders is selinux permissive. Mostly because we have never had enough cycles to track down any problems with making them enforcing. However, I just checked and the s390x builders _were_ in enforcing mode. ;( They are not installed like all the rest of our builders (via kickstarts), but via a install image the mainframe admins made for us. Sorry this wasn't noticed until now. ;( I've set them all in permissive and tweaked our ansible playbooks to make sure all of them stay that way. > I still want the system policy to account for GCL, in some way or > another. But, as you can see from the quoted text above, submitting a > pull request to the relevant git repository has resulted in months of > . And pointing that out on this list last weekend > has resulted in still more of the crickets. > > So ... what is a packager supposed to do Why is it so hard to get > any attention for submissions to the system SELinux policy? There > should be a barrier to entry; I understand that. But I can't even get > the gatekeeper to have a conversation with me. Hellp!!! > > Frustratedly yours, I don't know. Others have expressed frustration with selinux policy maintainers of late as well. It's really hard to say what the trouble is... are there to few of them? Overtasked with other work? Workflow too difficult? Perhaps we can get FESCO or someone to work with them and try and come up with a more open and working workflow. I'm not sure what the answer is here. kevin signature.asc Description: OpenPGP digital signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On 10/13/2017 11:07 PM, Jerry James wrote: But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. s390x before z14 is a read-implies-exec architecture, so the mprotect calls are probably unnecessary there. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: GCL and SELinux: help requested
On Fri, Oct 13, 2017 at 03:07:05PM -0600, Jerry James wrote: > But that's not the end of the fun. GCL failed the mass rebuild this > summer. It built successfully on every architecture but s390x. On > s390x, the build failed due to a failed call to mprotect(), almost > certainly a sign that SELinux was in enforcing mode on the builder. > Was that a known issue with s390x builders? And, if so, has it been > rectified since? If so, I'll try building again. AIUI the builders run with SELinux disabled. Has this changed? Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com libguestfs lets you edit virtual machines. Supports shell scripting, bindings from many languages. http://libguestfs.org ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
GCL and SELinux: help requested
On Sat, Oct 7, 2017 at 9:34 AM, Jerry Jameswrote: > I don't believe that anybody looks at those pull requests on a regular > basis. Should somebody be doing so? There are 8 pull requests, > dating back to about the time of the above conversation. Five of > those don't contain a single comment. > > I opened one for gcl on July 29, and added a comment a month later > asking if somebody was going to look at it. No response. This is a > bit annoying, considering that I opened a bugzilla request asking for > the same thing 4 years ago, and no action has ever been taken on it. > I thought maybe a PR would finally get something to happen. Nearly a week has gone by, and no answer. I'm really stumped about what to do. Let me summarize the whole long saga and solicit help. GCL is a Common Lisp implementation. It is known for its speed compared to other CL implementations. It has a long lineage, summarized here: https://en.wikipedia.org/wiki/GNU_Common_Lisp. I took over maintenance of the package in late 2008 when the previous maintainer did not have time to continue. At that point, the package did not build in Rawhide and was slated to be dropped from Fedora soon. I got it working with help from upstream and Daniel Walsh, who provided advice on putting together an SELinux policy to account for the fact that GCL produces executable code on the fly by calling mprotect on selected pages. Fast forward to 2013. By that time, the GCL policy also had to mention maxima executables, since executables built with GCL also use the GCL memory allocator. I figured that meant it was time to merge the GCL policy into the system policy, and consequently opened a bugzilla ticket. In spite of me trying to reboot the conversation a couple of times, those involved who held the SELinux reins for Fedora, Just. Could. Not. Stay. On. Topic. We talked about the execheap permission in general, and its place in the universe. Some of them sneeringly, condescendingly wondered why upstream and I were both so incompetent that we didn't just rewrite the allocator to use mmap. (Hint: it isn't easy, and upstream isn't interested in the exercise.) After multiple failures on my part to get something to happen, I gave up in despair. Fast forward to 2017. Attempts to build maxima with gcl on aarch64 started hanging at package install time. See https://bugzilla.redhat.com/show_bug.cgi?id=1435395. This was blamed on gcl, incorrectly I believe. As I pointed out in the bug, nothing built from gcl sources runs at package install time, so the hang must be happening inside one of fixfiles, semodule, or restorecon, which ARE run from the gcl install scripts because GCL has to install its own SELinux policy, due to that policy not being merged into the system policy. So, policycoreutils maintainers! Something Is Afoot on aarch64! But that's not the end of the fun. GCL failed the mass rebuild this summer. It built successfully on every architecture but s390x. On s390x, the build failed due to a failed call to mprotect(), almost certainly a sign that SELinux was in enforcing mode on the builder. Was that a known issue with s390x builders? And, if so, has it been rectified since? If so, I'll try building again. I still want the system policy to account for GCL, in some way or another. But, as you can see from the quoted text above, submitting a pull request to the relevant git repository has resulted in months of . And pointing that out on this list last weekend has resulted in still more of the crickets. So ... what is a packager supposed to do Why is it so hard to get any attention for submissions to the system SELinux policy? There should be a barrier to entry; I understand that. But I can't even get the gatekeeper to have a conversation with me. Hellp!!! Frustratedly yours, -- Jerry James http://www.jamezone.org/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org