coredumpctl change in jeopardy due to SELinux bugs

[Michael Catanzaro]

Hi,

Unfortunately the change deadline has passed, but our coredumpctl
change is not testable due to [1]. Additionally, ABRT is broken due to
[2]. We have workarounds for both issues, but it requires running
SELinux commands locally. Accordingly, is likely that FESCo will reject
the change at its next meeting.

I'm tired of prodding the SELinux developers via email and Bugzilla.
This saga has been ongoing since last summer, which is way too long. I
now have very, very serious doubts as to whether we should continue to
ship with SELinux enabled in the Workstation product. We clearly cannot
fix it even when it's breaking a critical developer feature that's a
priority for the WG... so what happens when it breaks anything less
important?

Michael

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980

[Stephen Gallagher]

On 03/03/2017 11:40 AM, Michael Catanzaro wrote:
>  Hi,
>  
>  Unfortunately the change deadline has passed, but our coredumpctl
>  change is not testable due to [1]. Additionally, ABRT is broken due to
>  [2]. We have workarounds for both issues, but it requires running
>  SELinux commands locally. Accordingly, is likely that FESCo will reject
>  the change at its next meeting.
>  
>  I'm tired of prodding the SELinux developers via email and Bugzilla.
>  This saga has been ongoing since last summer, which is way too long. I
>  now have very, very serious doubts as to whether we should continue to
>  ship with SELinux enabled in the Workstation product. We clearly cannot
>  fix it even when it's breaking a critical developer feature that's a
>  priority for the WG... so what happens when it breaks anything less
>  important?
>  
>  Michael
>  
>  [1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829
>  [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980 
Please propose [1] as a blocker bug for the release and open a ticket on the
FESCo tracker to request that FESCo use its prerogative to declare this a
blocker for the release.

[Bastien Nocera]

----- Original Message -----
>  Hi,
>  
>  Unfortunately the change deadline has passed, but our coredumpctl
>  change is not testable due to [1]. Additionally, ABRT is broken due to
>  [2]. We have workarounds for both issues, but it requires running
>  SELinux commands locally. Accordingly, is likely that FESCo will reject
>  the change at its next meeting.
>  
>  I'm tired of prodding the SELinux developers via email and Bugzilla.
>  This saga has been ongoing since last summer, which is way too long. I
>  now have very, very serious doubts as to whether we should continue to
>  ship with SELinux enabled in the Workstation product. We clearly cannot
>  fix it even when it's breaking a critical developer feature that's a
>  priority for the WG... so what happens when it breaks anything less
>  important? 
It broke creating galleries from Videos because of SELinux policies, it
broke all the iOS devices integration, it still breaks fwupd checking
for 8bitdo joypads. I usually run my systems with permissive SELinux,
because it's too much of a pain.

Now that the new systemd with restrictions is in rawhide, I would rather
we started using this functionality, meaning that the developers and
maintainers of those daemons are the ones saying what is correct behaviour
and what isn't.

For example, I recently restricted accesses in both fprintd and iio-sensor-proxy,
which interact with hardware:
https://cgit.freedesktop.org/libfprint/fprintd/tree/data/fprintd.service.in
https://github.com/hadess/iio-sensor-proxy/blob/master/data/iio-sensor-pr...

We need to start looking at shipping sandboxed applications. It makes
adding dependencies much less painful, and actually enhances security.

Cheers

[Matthew Miller]

On Fri, Mar 03, 2017 at 10:40:30AM -0600, Michael Catanzaro wrote:
>  I'm tired of prodding the SELinux developers via email and
> Bugzilla.
>  This saga has been ongoing since last summer, which is way too long. I 
This looks like it may be a candidate for Fedora Program Management's
new "Prioritized bugs and issues" process. See
https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_bugs...

I don't want to _over_ use this, but this kind of thing certainly seems
like a potential candidate.



-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Peter Robinson]

>  Unfortunately the change deadline has passed, but our coredumpctl
>  change is not testable due to [1]. Additionally, ABRT is broken due to
>  [2]. We have workarounds for both issues, but it requires running
>  SELinux commands locally. Accordingly, is likely that FESCo will reject
>  the change at its next meeting.
>
>  I'm tired of prodding the SELinux developers via email and Bugzilla.
>  This saga has been ongoing since last summer, which is way too long. I
>  now have very, very serious doubts as to whether we should continue to
>  ship with SELinux enabled in the Workstation product. We clearly cannot
>  fix it even when it's breaking a critical developer feature that's a
>  priority for the WG... so what happens when it breaks anything less
>  important? 
I think it still needs to be shipped enabled, but I agree the
whack-a-mole that the SELinux has become of late is quite the joke,
anyone would think they didn't have a decent set of tests/test harness
hooked into a CI system for every git pull request change that is
made.

[Michael Catanzaro]

On Fri, 2017-03-03 at 12:14 -0500, Matthew Miller wrote:
>  This looks like it may be a candidate for Fedora Program
> Management's
>  new "Prioritized bugs and issues" process. See
>  https://fedoraproject.org/wiki/Fedora_Program_Management/Prioritized_
>  bugs_and_issues_-_the_process
>  
>  I don't want to _over_ use this, but this kind of thing certainly
>  seems
>  like a potential candidate. 
See [1]. It's already been rejected, but I could submit the same bug
again, I suppose.

Michael

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829#c28

[Paul W. Frields]

On Fri, Mar 03, 2017 at 11:57:12AM -0500, Stephen Gallagher wrote:
>  On 03/03/2017 11:40 AM, Michael Catanzaro wrote:
>  > Hi,
>  > 
>  > Unfortunately the change deadline has passed, but our coredumpctl
>  > change is not testable due to [1]. Additionally, ABRT is broken due to
>  > [2]. We have workarounds for both issues, but it requires running
>  > SELinux commands locally. Accordingly, is likely that FESCo will reject
>  > the change at its next meeting.
>  > 
>  > I'm tired of prodding the SELinux developers via email and Bugzilla.
>  > This saga has been ongoing since last summer, which is way too long. I
>  > now have very, very serious doubts as to whether we should continue to
>  > ship with SELinux enabled in the Workstation product. We clearly cannot
>  > fix it even when it's breaking a critical developer feature that's a
>  > priority for the WG... so what happens when it breaks anything less
>  > important?
>  > 
>  > Michael
>  > 
>  > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829
>  > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980
>  
>  Please propose [1] as a blocker bug for the release and open a ticket on the
>  FESCo tracker to request that FESCo use its prerogative to declare this a
>  blocker for the release. 
[1] is in MODIFIED and selinux-policy-3.13.1-235.fc26 was supposed to
have the fix.  Michael, are you saying the fix isn't working?  Because
I see no comment in the bug to that effect.

Putting that on the blocker list may be useful, but what would be more
useful is testing the bug and reporting the results back.



-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Lukas Vrabec]

On 03/03/2017 10:43 PM, Paul W. Frields wrote:
>  On Fri, Mar 03, 2017 at 11:57:12AM -0500, Stephen Gallagher wrote:
> > On 03/03/2017 11:40 AM, Michael Catanzaro wrote:
> >> Hi,
> >>
> >> Unfortunately the change deadline has passed, but our coredumpctl
> >> change is not testable due to [1]. Additionally, ABRT is broken due to
> >> [2]. We have workarounds for both issues, but it requires running
> >> SELinux commands locally. Accordingly, is likely that FESCo will reject
> >> the change at its next meeting.
> >>
> >> I'm tired of prodding the SELinux developers via email and Bugzilla.
> >> This saga has been ongoing since last summer, which is way too long. I
> >> now have very, very serious doubts as to whether we should continue to
> >> ship with SELinux enabled in the Workstation product. We clearly cannot
> >> fix it even when it's breaking a critical developer feature that's a
> >> priority for the WG... so what happens when it breaks anything less
> >> important?
> >>
> >> Michael
> >>
> >> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829
> >> [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980
> >
> > Please propose [1] as a blocker bug for the release and open a ticket on the
> > FESCo tracker to request that FESCo use its prerogative to declare this a
> > blocker for the release.
>
>  [1] is in MODIFIED and selinux-policy-3.13.1-235.fc26 was supposed to
>  have the fix.  Michael, are you saying the fix isn't working?  Because
>  I see no comment in the bug to that effect.
>
>  Putting that on the blocker list may be useful, but what would be more
>  useful is testing the bug and reporting the results back.
>
>
>  
I add comment to BZ, it's fixed in the latest selinux-policy package for 
F26.

Lukas.

-- 
Lukas Vrabec
SELinux Solutions
Red Hat, Inc.

[Michael Catanzaro]

Hi,

Lukas just commented half an hour ago (thanks Lukas!) to say it's now fixed. There was
no previous indication in the bug that a fix was available. So hopefully that's one of
the two issues down....

Michael

[Lukas Vrabec]

Sorry I forgot update BZ but Fix is in the latest policy.
Also, issue with abrt_dump_oops_t is already fixed in policy.

Please let me know if you have any troubles around SELinux policy, I'll 
try to fix it ASAP.

On 03/03/2017 11:14 PM, Michael Catanzaro wrote:
>  Hi,
>
>  Lukas just commented half an hour ago (thanks Lukas!) to say it's now fixed. There
> was no previous indication in the bug that a fix was available. So hopefully that's
> one of the two issues down....
>
>  Michael
>  _______________________________________________
>  desktop mailing list -- desktop(a)lists.fedoraproject.org
>  To unsubscribe send an email to desktop-leave(a)lists.fedoraproject.org
>  

-- 
Lukas Vrabec
SELinux Solutions
Red Hat, Inc.

[Michael Catanzaro]

OK, Lukas says the second issue is fixed now, too. \o/

I'm still concerned with how difficult it was to resolve this. :(

Michael

[Paul W. Frields]

On Fri, Mar 03, 2017 at 04:43:37PM -0500, Paul W. Frields wrote:
>  On Fri, Mar 03, 2017 at 11:57:12AM -0500, Stephen Gallagher wrote:
>  > On 03/03/2017 11:40 AM, Michael Catanzaro wrote:
>  > > Hi,
>  > > 
>  > > Unfortunately the change deadline has passed, but our coredumpctl
>  > > change is not testable due to [1]. Additionally, ABRT is broken due to
>  > > [2]. We have workarounds for both issues, but it requires running
>  > > SELinux commands locally. Accordingly, is likely that FESCo will reject
>  > > the change at its next meeting.
>  > > 
>  > > I'm tired of prodding the SELinux developers via email and Bugzilla.
>  > > This saga has been ongoing since last summer, which is way too long. I
>  > > now have very, very serious doubts as to whether we should continue to
>  > > ship with SELinux enabled in the Workstation product. We clearly cannot
>  > > fix it even when it's breaking a critical developer feature that's a
>  > > priority for the WG... so what happens when it breaks anything less
>  > > important?
>  > > 
>  > > Michael
>  > > 
>  > > [1] https://bugzilla.redhat.com/show_bug.cgi?id=1341829
>  > > [2] https://bugzilla.redhat.com/show_bug.cgi?id=1419980
>  > 
>  > Please propose [1] as a blocker bug for the release and open a ticket on the
>  > FESCo tracker to request that FESCo use its prerogative to declare this a
>  > blocker for the release.
>  
>  [1] is in MODIFIED and selinux-policy-3.13.1-235.fc26 was supposed to
>  have the fix.  Michael, are you saying the fix isn't working?  Because
>  I see no comment in the bug to that effect.
>  
>  Putting that on the blocker list may be useful, but what would be more
>  useful is testing the bug and reporting the results back. 
Looks like from recent bug comments that both of these fixes are
already in F26.  Can you test to see if they take care of the issue?


-- 
Paul W. Frields                                http://paul.frields.org/
  gpg fingerprint: 3DA6 A0AC 6D58 FEC4 0233  5906 ACDB C937 BD11 3717
  http://redhat.com/   -  -  -  -   http://pfrields.fedorapeople.org/
    The open source story continues to grow: http://opensource.com

[Michael Catanzaro]

On Fri, 2017-03-03 at 17:37 -0500, Paul W. Frields wrote:
>  Looks like from recent bug comments that both of these fixes are
>  already in F26.  Can you test to see if they take care of the issue? 
I'll definitely test it whenever I next get around to installing F26.

Thanks,

Michael

[Matthew Miller]

On Fri, Mar 03, 2017 at 03:30:44PM -0600, Michael Catanzaro wrote:
>  See [1]. It's already been rejected, but I could submit the same
> bug
>  again, I suppose. 
Oh yeah: "It seems likely that this will end up fixed as a dependency
of other changes in Fedora Workstation, so I don't think we need to
call it out as requiring special attention". If that's not working, it
might be indicative of bigger communication problems. But, in any case,
I think if a prioritized bug is not accepted as such for a reason like
the above, and then that reason is not working out, revisiting makes
sense.

In any case... it seems like it *did* get fixed?

-- 
Matthew Miller
<mattdm(a)fedoraproject.org&gt;
Fedora Project Leader

[Michael Catanzaro]

On Sat, 2017-03-04 at 10:04 -0500, Matthew Miller wrote:
>  In any case... it seems like it *did* get fixed? 
Seems so, though both bug reports are still open.

Michael