Re: GCL and SELinux: help requested

2017-11-23 Thread Javier Martinez Canillas
On Thu, Nov 23, 2017 at 10:21 AM, Lukas Vrabec  wrote:
> 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

2017-11-23 Thread Lukas Vrabec

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

2017-11-23 Thread Javier Martinez Canillas
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.

> 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

2017-10-24 Thread Petr Lautrbach
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

2017-10-24 Thread Petr Lautrbach
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

2017-10-24 Thread Dominik 'Rathann' Mierzejewski
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

2017-10-23 Thread Lukas Vrabec

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

2017-10-21 Thread Kevin Fenzi
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

2017-10-20 Thread Lukas Vrabec

On 10/13/2017 11:07 PM, Jerry James wrote:

On Sat, Oct 7, 2017 at 9:34 AM, Jerry James  wrote:

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

2017-10-16 Thread Richard W.M. Jones
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

2017-10-16 Thread Florian Weimer

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

2017-10-16 Thread Japheth Cleaver

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

2017-10-16 Thread John Florian
> 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

2017-10-13 Thread James Hogarth
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

2017-10-13 Thread Adam Williamson
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

2017-10-13 Thread Kevin Fenzi
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

2017-10-13 Thread Adam Williamson
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

2017-10-13 Thread Kevin Fenzi
On 10/13/2017 02:07 PM, Jerry James wrote:
> On Sat, Oct 7, 2017 at 9:34 AM, Jerry James  wrote:

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

2017-10-13 Thread Florian Weimer

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

2017-10-13 Thread Richard W.M. Jones
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

2017-10-13 Thread Jerry James
On Sat, Oct 7, 2017 at 9:34 AM, Jerry James  wrote:
> 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