Re: Policy capabilities: when to use and complications with using

[Dominick Grift <dac.override@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 4164 bytes --]

On Thu, May 04, 2017 at 09:22:22PM +0200, Petr Lautrbach wrote:
> On 05/04/2017 07:50 PM, Dominick Grift wrote:
> > On Thu, May 04, 2017 at 07:42:40PM +0200, Dominick Grift wrote:
> >> On Thu, May 04, 2017 at 11:50:15AM -0400, Paul Moore wrote:
> >>> On Wed, May 3, 2017 at 12:51 PM, Dominick Grift <dac.override@gmail.com> wrote:
> >>>> On Wed, May 03, 2017 at 12:14:16PM -0400, Stephen Smalley wrote:
> >>>>> Part of the reason that we tend to not introduce a new policy
> >>>>> capability more often is that it is painful to do so currently.  We
> >>>>> have to patch libsepol to recognize the new capability and patch the
> >>>>> policy to declare it (although for the latter we can now declare them
> >>>>> via a CIL module without modifying the base policy).  And since the
> >>>>> policy or module won't build without the updated libsepol, we can't
> >>>>> turn on the capability by default in refpolicy without making it
> >>>>> dependent on a new libsepol version.  That's why extended_socket_class
> >>>>> isn't yet enabled in refpolicy, for example.  That causes enablement
> >>>>> and adoption to lag behind.  It also makes it harder to test the new
> >>>>> kernel feature in the first place.
> >>>>
> >>>> I would like to see Fedora package the RC's in Rawhide as well (other distributions could help by packaging the RC's in unstable as well). That would atleast make the RC's a bit more accessible.
> >>>> In Fedora it is usually not the kernel that is the problem, it is user space that is generally to old. And as you've said policy is no longer a problem with CIL.
> >>>
> >>> [NOTE: I'm still thinking about the rest of Stephen's email, and the
> >>> follow up comments, but I wanted to reply to this particular comment
> >>> separately.]
> >>>
> >>> I'm not sure I want to see SELinux userspace release candidates in
> >>> normal Rawhide, but I think creating a COPR repository to
> >>> build/distribute release candidates could be a good thing.  We already
> >>> do something similar for the kernel patches and it has been helpful in
> >>> my opinion.
> >>
> >> Thanks, Yes i suppose you are right. Release Candidates would probably potentially cause too much disruption even in Rawhide.
> >> COPR should do the job, although will not be as accessible as Rawhide. It won't get the same kind of attention, but it will do for me.
> > 
> > With COPR though we might be able to package more frequent and not just RC's (weekly's/nightly's)? If that can somehow be automated  then we also do not have to worrie so much about keeping things maintained over time
> 
> 
> I'm just building new set of updates in my COPR plautrba/selinux
> repository [1]. It's based on latest upstream sources with some Fedora
> patches on the top of it currently tracked in my github tree [2]. But
> there are some problems and it's not ready yet.

Most of the fedora specific patches I will probably not be able to test. I don't (can't) use semanage, policycoreutils-GUI etc.
I am mainly able to test libselinux, libsepol and policycoreutils

> 
> I used to build vanilla upstream sources [3] but the latest build is 15
> months old. I can restart this project if there's an interest.

That would be nice, especially if it could be automated. So that I have some kind of assurance that it is maintained.
I dont add COPRs much but when i do i intent to keep using them consistently. I wouldnt want to have dead COPR repositories to worry about.

> 
> Since COPR provides API with an authentication token, builds can
> automated and I have few scripts I used before.
> 
> I think it could even work for Rawhide with less frequent update cycle.

I would prefer Rawhide because then we reach a broader audience.

> 
> [1] https://copr.fedorainfracloud.org/coprs/plautrba/selinux/
> [2] https://github.com/bachradsusi/selinux/tree/WIP-master
> [3] https://copr.fedorainfracloud.org/coprs/plautrba/selinux-master/builds/
> 
> Petr

Thanks!

-- 
Key fingerprint = 5F4D 3CDB D3F8 3652 FBD8  02D5 3B6C 5F1D 2C7B 6B02
https://sks-keyservers.net/pks/lookup?op=get&search=0x3B6C5F1D2C7B6B02
Dominick Grift

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 659 bytes --]