[GIT PULL] SELinux patches for 4.1

[GIT PULL] SELinux patches for 4.1

[Paul Moore]

Hi James,

Five patches this time around: three patches to improve and enlarge the the 
avtab hash table, one to cleanup some MLS label import code, and one to 
cleanup some of the avc code.  All of the patches are pretty small and 
straightforward.  The two cleanup patches are trivially understandable and the 
avtab code is well documented.

As usual, all patches pass the SELinux testsuite.

Enjoy,
-Paul

---
The following changes since commit 6436a123a147db51a0b06024a8350f4c230e73ff:

  selinux: fix sel_write_enforce broken return value
           (2015-03-25 16:55:06 -0400)

are available in the git repository at:

  git://git.infradead.org/users/pcmoore/selinux upstream

for you to fetch changes up to 9b43e04b188a1f715429604cca32b846e5a48cd2:

  Merge branch 'next' into upstream in preparation for v4.1
  (2015-04-01 22:24:51 -0400)

----------------------------------------------------------------
Jeff Vander Stoep (1):
      selinux: remove unnecessary pointer reassignment in 
               avc_has_perm_noaudit()

John Brooks (1):
      selinux: Use a better hash function for avtab

Paul Moore (2):
      selinux: reconcile security_netlbl_secattr_to_sid() and 
               mls_import_netlbl_cat()
      Merge branch 'next' into upstream in preparation for v4.1

Stephen Smalley (2):
      selinux: convert avtab hash table to flex_array
      selinux: increase avtab max buckets

 security/selinux/avc.c         |  6 ++--
 security/selinux/ss/avtab.c    | 72 +++++++++++++++++++++++++++++++---------
 security/selinux/ss/avtab.h    |  8 +++--
 security/selinux/ss/mls.c      | 10 ++----
 security/selinux/ss/services.c |  6 +---
 5 files changed, 67 insertions(+), 35 deletions(-)

-- 
paul moore
security @ redhat

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Wed, 1 Apr 2015, Paul Moore wrote:

> Hi James,
> 
> Five patches this time around: three patches to improve and enlarge the the 
> avtab hash table, one to cleanup some MLS label import code, and one to 
> cleanup some of the avc code.  All of the patches are pretty small and 
> straightforward.  The two cleanup patches are trivially understandable and the 
> avtab code is well documented.
> 
> As usual, all patches pass the SELinux testsuite.
> 
> Enjoy,
> -Paul
> 
> ---
> The following changes since commit 6436a123a147db51a0b06024a8350f4c230e73ff:
> 
>   selinux: fix sel_write_enforce broken return value
>            (2015-03-25 16:55:06 -0400)
> 
> are available in the git repository at:
> 
>   git://git.infradead.org/users/pcmoore/selinux upstream
> 
> for you to fetch changes up to 9b43e04b188a1f715429604cca32b846e5a48cd2:
> 
>   Merge branch 'next' into upstream in preparation for v4.1
>   (2015-04-01 22:24:51 -0400)
> 

Is this branch downstream from my -next?


-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

On Thursday, April 02, 2015 11:32:02 PM James Morris wrote:
> On Wed, 1 Apr 2015, Paul Moore wrote:
> > Hi James,
> > 
> > Five patches this time around: three patches to improve and enlarge the
> > the
> > avtab hash table, one to cleanup some MLS label import code, and one to
> > cleanup some of the avc code.  All of the patches are pretty small and
> > straightforward.  The two cleanup patches are trivially understandable and
> > the avtab code is well documented.
> > 
> > As usual, all patches pass the SELinux testsuite.
> > 
> > Enjoy,
> > -Paul
> > 
> > ---
> > 
> > The following changes since commit 
6436a123a147db51a0b06024a8350f4c230e73ff:
> >   selinux: fix sel_write_enforce broken return value
> >   
> >            (2015-03-25 16:55:06 -0400)
> > 
> > are available in the git repository at:
> >   git://git.infradead.org/users/pcmoore/selinux upstream
> > 
> > for you to fetch changes up to 9b43e04b188a1f715429604cca32b846e5a48cd2:
> >   Merge branch 'next' into upstream in preparation for v4.1
> >   (2015-04-01 22:24:51 -0400)
> 
> Is this branch downstream from my -next?

It should be, although likely an older version as I try not to pull unless 
necessary to resolve conflicts.  When I do a test merge into your next branch 
I see the following:

  #git pull selinux next
  From git://git.infradead.org/users/pcmoore/selinux
   * branch            next       -> FETCH_HEAD
  Auto-merging security/selinux/selinuxfs.c
  Merge made by the 'recursive' strategy.
   security/selinux/avc.c         |  6 ++--
   security/selinux/selinuxfs.c   |  2 +-
   security/selinux/ss/avtab.c    | 72 +++++++++++++++++++++++++++++---------
   security/selinux/ss/avtab.h    |  8 +++--
   security/selinux/ss/mls.c      | 10 ++----
   security/selinux/ss/services.c |  6 +---
   6 files changed, 68 insertions(+), 36 deletions(-)

The merge diffstat looks as I would expect, the only odd thing is selinuxfs.c, 
but it looks like that is simply because your next branch doesn't include the 
error code fix I sent you for v4.0:

  commit 6436a123a147db51a0b06024a8350f4c230e73ff
  Author: Joe Perches <joe@perches.com>
  Date:   Mon Mar 23 18:01:35 2015 -0700

    selinux: fix sel_write_enforce broken return value
    
    Return a negative error value like the rest of the entries in this  
    function.
    
    Cc: <stable@vger.kernel.org>
    Signed-off-by: Joe Perches <joe@perches.com>
    Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>
    [PM: tweaked subject line]
    Signed-off-by: Paul Moore <pmoore@redhat.com>

Are you asking because you ran into a problem, or just to check?

-- 
paul moore
security @ redhat

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Thu, 2 Apr 2015, Paul Moore wrote:

> necessary to resolve conflicts.  When I do a test merge into your next branch 
> I see the following:
> 
>   #git pull selinux next
>   From git://git.infradead.org/users/pcmoore/selinux
>    * branch            next       -> FETCH_HEAD
>   Auto-merging security/selinux/selinuxfs.c
>   Merge made by the 'recursive' strategy.
>    security/selinux/avc.c         |  6 ++--
>    security/selinux/selinuxfs.c   |  2 +-
>    security/selinux/ss/avtab.c    | 72 +++++++++++++++++++++++++++++---------
>    security/selinux/ss/avtab.h    |  8 +++--
>    security/selinux/ss/mls.c      | 10 ++----
>    security/selinux/ss/services.c |  6 +---
>    6 files changed, 68 insertions(+), 36 deletions(-)
> 
> The merge diffstat looks as I would expect, the only odd thing is selinuxfs.c, 
> but it looks like that is simply because your next branch doesn't include the 
> error code fix I sent you for v4.0:
> 
>   commit 6436a123a147db51a0b06024a8350f4c230e73ff
>   Author: Joe Perches <joe@perches.com>
>   Date:   Mon Mar 23 18:01:35 2015 -0700
> 
>     selinux: fix sel_write_enforce broken return value
>     
>     Return a negative error value like the rest of the entries in this  
>     function.
>     
>     Cc: <stable@vger.kernel.org>
>     Signed-off-by: Joe Perches <joe@perches.com>
>     Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>
>     [PM: tweaked subject line]
>     Signed-off-by: Paul Moore <pmoore@redhat.com>
> 
> Are you asking because you ran into a problem, or just to check?

Yep, I saw that and some backmerge strangeness.  Did you rebase your tree
after I created a fresh branch?


-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

On Thu, Apr 2, 2015 at 10:45 PM, James Morris <jmorris@namei.org> wrote:
> On Thu, 2 Apr 2015, Paul Moore wrote:
>
>> necessary to resolve conflicts.  When I do a test merge into your next branch
>> I see the following:
>>
>>   #git pull selinux next
>>   From git://git.infradead.org/users/pcmoore/selinux
>>    * branch            next       -> FETCH_HEAD
>>   Auto-merging security/selinux/selinuxfs.c
>>   Merge made by the 'recursive' strategy.
>>    security/selinux/avc.c         |  6 ++--
>>    security/selinux/selinuxfs.c   |  2 +-
>>    security/selinux/ss/avtab.c    | 72 +++++++++++++++++++++++++++++---------
>>    security/selinux/ss/avtab.h    |  8 +++--
>>    security/selinux/ss/mls.c      | 10 ++----
>>    security/selinux/ss/services.c |  6 +---
>>    6 files changed, 68 insertions(+), 36 deletions(-)
>>
>> The merge diffstat looks as I would expect, the only odd thing is selinuxfs.c,
>> but it looks like that is simply because your next branch doesn't include the
>> error code fix I sent you for v4.0:
>>
>>   commit 6436a123a147db51a0b06024a8350f4c230e73ff
>>   Author: Joe Perches <joe@perches.com>
>>   Date:   Mon Mar 23 18:01:35 2015 -0700
>>
>>     selinux: fix sel_write_enforce broken return value
>>
>>     Return a negative error value like the rest of the entries in this
>>     function.
>>
>>     Cc: <stable@vger.kernel.org>
>>     Signed-off-by: Joe Perches <joe@perches.com>
>>     Acked-by:  Stephen Smalley <sds@tycho.nsa.gov>
>>     [PM: tweaked subject line]
>>     Signed-off-by: Paul Moore <pmoore@redhat.com>
>>
>> Are you asking because you ran into a problem, or just to check?
>
> Yep, I saw that and some backmerge strangeness.  Did you rebase your tree
> after I created a fresh branch?

It looks like I'm based off your tree from Feb 1st, the last commit
from your tree looks to be: 11cd64a234d5a1a7111627ef947beb0e5fad9e71.

Do you need me to rebase?

-- 
paul moore
www.paul-moore.com

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Fri, 3 Apr 2015, Paul Moore wrote:

> > Yep, I saw that and some backmerge strangeness.  Did you rebase your tree
> > after I created a fresh branch?
> 
> It looks like I'm based off your tree from Feb 1st, the last commit
> from your tree looks to be: 11cd64a234d5a1a7111627ef947beb0e5fad9e71.
> 
> Do you need me to rebase?
> 

Yep, see if that fixes things.


-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

On Fri, Apr 3, 2015 at 11:07 AM, James Morris <jmorris@namei.org> wrote:
> On Fri, 3 Apr 2015, Paul Moore wrote:
>
>> > Yep, I saw that and some backmerge strangeness.  Did you rebase your tree
>> > after I created a fresh branch?
>>
>> It looks like I'm based off your tree from Feb 1st, the last commit
>> from your tree looks to be: 11cd64a234d5a1a7111627ef947beb0e5fad9e71.
>>
>> Do you need me to rebase?
>>
>
> Yep, see if that fixes things.

Okay, try it now; I rebased selinux#upstream against your latest next
branch.  The same patches are included, just in a slightly different
order, and I included the error code fix for -stable since it isn't in
your next branch or Linus' current.

  # git pull git://git.infradead.org/users/pcmoore/selinux upstream
  From git://git.infradead.org/users/pcmoore/selinux
   * branch            upstream   -> FETCH_HEAD
  Updating 4f9a60f..6ad2606
  Fast-forward
   security/selinux/avc.c         |  6 ++--
   security/selinux/selinuxfs.c   |  2 +-
   security/selinux/ss/avtab.c    | 72
++++++++++++++++++++++++++++++++----------
   security/selinux/ss/avtab.h    |  8 +++--
   security/selinux/ss/mls.c      | 10 ++----
   security/selinux/ss/services.c |  6 +---
   6 files changed, 68 insertions(+), 36 deletions(-)

-- 
paul moore
www.paul-moore.com

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Fri, 3 Apr 2015, Paul Moore wrote:

> On Fri, Apr 3, 2015 at 11:07 AM, James Morris <jmorris@namei.org> wrote:
> > On Fri, 3 Apr 2015, Paul Moore wrote:
> >
> >> > Yep, I saw that and some backmerge strangeness.  Did you rebase your tree
> >> > after I created a fresh branch?
> >>
> >> It looks like I'm based off your tree from Feb 1st, the last commit
> >> from your tree looks to be: 11cd64a234d5a1a7111627ef947beb0e5fad9e71.
> >>
> >> Do you need me to rebase?
> >>
> >
> > Yep, see if that fixes things.
> 
> Okay, try it now; I rebased selinux#upstream against your latest next
> branch.  The same patches are included, just in a slightly different
> order, and I included the error code fix for -stable since it isn't in
> your next branch or Linus' current.
> 

It's in Linus' current as 6436a123a147db51a

-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

I'll have to look closer when I'm back in front of a system, perhaps I 
missed it.

More importantly, did you pull from the SELinux upstream branch?

--
paul moore
www.paul-moore.com



On April 4, 2015 11:49:29 AM James Morris <jmorris@namei.org> wrote:

> On Fri, 3 Apr 2015, Paul Moore wrote:
>
> > On Fri, Apr 3, 2015 at 11:07 AM, James Morris <jmorris@namei.org> wrote:
> > > On Fri, 3 Apr 2015, Paul Moore wrote:
> > >
> > >> > Yep, I saw that and some backmerge strangeness.  Did you rebase your 
> tree
> > >> > after I created a fresh branch?
> > >>
> > >> It looks like I'm based off your tree from Feb 1st, the last commit
> > >> from your tree looks to be: 11cd64a234d5a1a7111627ef947beb0e5fad9e71.
> > >>
> > >> Do you need me to rebase?
> > >>
> > >
> > > Yep, see if that fixes things.
> >
> > Okay, try it now; I rebased selinux#upstream against your latest next
> > branch.  The same patches are included, just in a slightly different
> > order, and I included the error code fix for -stable since it isn't in
> > your next branch or Linus' current.
> >
>
> It's in Linus' current as 6436a123a147db51a
>
> --
> James Morris
> <jmorris@namei.org>
>

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Sat, 4 Apr 2015, Paul Moore wrote:

> I'll have to look closer when I'm back in front of a system, perhaps I missed
> it.
> 
> More importantly, did you pull from the SELinux upstream branch?
> 

Nope.

> --
> paul moore
> www.paul-moore.com
> 
> 
> 
> On April 4, 2015 11:49:29 AM James Morris <jmorris@namei.org> wrote:
> 
> > On Fri, 3 Apr 2015, Paul Moore wrote:
> >
> > > On Fri, Apr 3, 2015 at 11:07 AM, James Morris <jmorris@namei.org> wrote:
> > > > On Fri, 3 Apr 2015, Paul Moore wrote:
> > > >
> > > > > > Yep, I saw that and some backmerge strangeness.  Did you rebase your 
> > tree
> > > > > > after I created a fresh branch?
> > > > >
> > > > > It looks like I'm based off your tree from Feb 1st, the last commit
> > > > > from your tree looks to be: 11cd64a234d5a1a7111627ef947beb0e5fad9e71.
> > > > >
> > > > > Do you need me to rebase?
> > > > >
> > > >
> > > > Yep, see if that fixes things.
> > >
> > > Okay, try it now; I rebased selinux#upstream against your latest next
> > > branch.  The same patches are included, just in a slightly different
> > > order, and I included the error code fix for -stable since it isn't in
> > > your next branch or Linus' current.
> > >
> >
> > It's in Linus' current as 6436a123a147db51a
> >
> > --
> > James Morris
> > <jmorris@namei.org>
> >
> 
> 

-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

You know James, we could probably shorten this process tremendously if you 
could respond with a sentence or two instead of a single word :-)

So you didn't pull the SELinux tree, is that because you simply haven't had 
time yet? Or is it because you don't like something in the tree? If the 
latter, can you expand upon what you don't like so I can remedy it?

--
paul moore
www.paul-moore.com



On April 6, 2015 9:14:24 AM James Morris <jmorris@namei.org> wrote:

> On Sat, 4 Apr 2015, Paul Moore wrote:
>
> > I'll have to look closer when I'm back in front of a system, perhaps I missed
> > it.
> >
> > More importantly, did you pull from the SELinux upstream branch?
> >
>
> Nope.
>
> > --
> > paul moore
> > www.paul-moore.com
> >
> >
> >
> > On April 4, 2015 11:49:29 AM James Morris <jmorris@namei.org> wrote:
> >
> > > On Fri, 3 Apr 2015, Paul Moore wrote:
> > >
> > > > On Fri, Apr 3, 2015 at 11:07 AM, James Morris <jmorris@namei.org> wrote:
> > > > > On Fri, 3 Apr 2015, Paul Moore wrote:
> > > > >
> > > > > > > Yep, I saw that and some backmerge strangeness.  Did you rebase 
> your
> > > tree
> > > > > > > after I created a fresh branch?
> > > > > >
> > > > > > It looks like I'm based off your tree from Feb 1st, the last commit
> > > > > > from your tree looks to be: 11cd64a234d5a1a7111627ef947beb0e5fad9e71.
> > > > > >
> > > > > > Do you need me to rebase?
> > > > > >
> > > > >
> > > > > Yep, see if that fixes things.
> > > >
> > > > Okay, try it now; I rebased selinux#upstream against your latest next
> > > > branch.  The same patches are included, just in a slightly different
> > > > order, and I included the error code fix for -stable since it isn't in
> > > > your next branch or Linus' current.
> > > >
> > >
> > > It's in Linus' current as 6436a123a147db51a
> > >
> > > --
> > > James Morris
> > > <jmorris@namei.org>
> > >
> >
> >
>
> --
> James Morris
> <jmorris@namei.org>
>

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Mon, 6 Apr 2015, Paul Moore wrote:

> You know James, we could probably shorten this process tremendously if you
> could respond with a sentence or two instead of a single word :-)
> 
> So you didn't pull the SELinux tree, is that because you simply haven't had
> time yet? Or is it because you don't like something in the tree? If the
> latter, can you expand upon what you don't like so I can remedy it?
> 

I haven't pulled from it because you still have a patch in there which is 
in Linus' tree.



> --
> paul moore
> www.paul-moore.com
> 
> 
> 
> On April 6, 2015 9:14:24 AM James Morris <jmorris@namei.org> wrote:
> 
> > On Sat, 4 Apr 2015, Paul Moore wrote:
> >
> > > I'll have to look closer when I'm back in front of a system, perhaps I
> > > missed
> > > it.
> > >
> > > More importantly, did you pull from the SELinux upstream branch?
> > >
> >
> > Nope.
> >
> > > --
> > > paul moore
> > > www.paul-moore.com
> > >
> > >
> > >
> > > On April 4, 2015 11:49:29 AM James Morris <jmorris@namei.org> wrote:
> > >
> > > > On Fri, 3 Apr 2015, Paul Moore wrote:
> > > >
> > > > > On Fri, Apr 3, 2015 at 11:07 AM, James Morris <jmorris@namei.org>
> > > > > wrote:
> > > > > > On Fri, 3 Apr 2015, Paul Moore wrote:
> > > > > >
> > > > > > > > Yep, I saw that and some backmerge strangeness.  Did you rebase 
> > your
> > > > tree
> > > > > > > > after I created a fresh branch?
> > > > > > >
> > > > > > > It looks like I'm based off your tree from Feb 1st, the last
> > > > > > > commit
> > > > > > > from your tree looks to be:
> > > > > > > 11cd64a234d5a1a7111627ef947beb0e5fad9e71.
> > > > > > >
> > > > > > > Do you need me to rebase?
> > > > > > >
> > > > > >
> > > > > > Yep, see if that fixes things.
> > > > >
> > > > > Okay, try it now; I rebased selinux#upstream against your latest next
> > > > > branch.  The same patches are included, just in a slightly different
> > > > > order, and I included the error code fix for -stable since it isn't in
> > > > > your next branch or Linus' current.
> > > > >
> > > >
> > > > It's in Linus' current as 6436a123a147db51a
> > > >
> > > > --
> > > > James Morris
> > > > <jmorris@namei.org>
> > > >
> > >
> > >
> >
> > --
> > James Morris
> > <jmorris@namei.org>
> >
> 
> 

-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Tue, 7 Apr 2015, James Morris wrote:

> On Mon, 6 Apr 2015, Paul Moore wrote:
> 
> > You know James, we could probably shorten this process tremendously if you
> > could respond with a sentence or two instead of a single word :-)
> > 
> > So you didn't pull the SELinux tree, is that because you simply haven't had
> > time yet? Or is it because you don't like something in the tree? If the
> > latter, can you expand upon what you don't like so I can remedy it?
> > 
> 
> I haven't pulled from it because you still have a patch in there which is 
> in Linus' tree.

You should be working downstream from my next branch.  When I pull from 
you, it should merge cleanly.


-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

On Tuesday, April 07, 2015 12:04:59 AM James Morris wrote:
> On Mon, 6 Apr 2015, Paul Moore wrote:
> > You know James, we could probably shorten this process tremendously if you
> > could respond with a sentence or two instead of a single word :-)
> > 
> > So you didn't pull the SELinux tree, is that because you simply haven't
> > had time yet? Or is it because you don't like something in the tree? If
> > the latter, can you expand upon what you don't like so I can remedy it?
> 
> I haven't pulled from it because you still have a patch in there which is
> in Linus' tree.

See, that wasn't so hard to type out :)

Removed the patch, it should now just contain the five patches described at 
the start, and shown again below.  It's based again the current security#next 
branch so there should be no problems, at least there haven't been in my test 
pulls.

On Tuesday, April 07, 2015 12:09:56 AM James Morris wrote:
> You should be working downstream from my next branch.  When I pull from
> you, it should merge cleanly.

I am working downstream from your next branch (the selinux#upstream branch is 
based on security#next), I have been for some time now.  I've posted online 
how I manage the SELinux tree (and audit tree if that matters) and if there 
are any changes I post updates; here it is in case you're curious:

  1. Create a new branch, stable-X.XX, set to the upstream branch that
     was sent during the merge window.

  2. Reset the next branch to the upstream branch that was sent during
     the merge window.

  3. Accept new features into the next branch and fixes into the
     stable-X.XX branch.

  4. As necessary, merge stable-X.XX into upstream and send pull
     requests upstream.

  5. When vX.XX is released, merge next into upstream and send a pull
     request for the upstream branch.  Leave stable-3.XX untouched for
     future stable fixes.

  6. Goto step #1.

It might be helpful if you posted how you manage the security tree.

---
The following changes since commit 4f9a60f5c7e74f3e413a1ede1e8b959d01df4e57:

  Merge branch 'smack-for-4.1' of git://github.com/cschaufler/smack-next into 
    next (2015-04-02 11:03:58 +1100)

are available in the git repository at:

  git://git.infradead.org/users/pcmoore/selinux upstream

for you to fetch changes up to cf7b6c0205f11cdb015384244c0b423b00e35c69:

  selinux: increase avtab max buckets (2015-04-06 20:16:23 -0400)

----------------------------------------------------------------
Jeff Vander Stoep (1):
      selinux: remove unnecessary pointer reassignment

John Brooks (1):
      selinux: Use a better hash function for avtab

Paul Moore (1):
      selinux: reconcile security_netlbl_secattr_to_sid() and
               mls_import_netlbl_cat()

Stephen Smalley (2):
      selinux: convert avtab hash table to flex_array
      selinux: increase avtab max buckets

 security/selinux/avc.c         |  6 ++--
 security/selinux/ss/avtab.c    | 72 ++++++++++++++++++++++++++++++---------
 security/selinux/ss/avtab.h    |  8 +++--
 security/selinux/ss/mls.c      | 10 ++----
 security/selinux/ss/services.c |  6 +---
 5 files changed, 67 insertions(+), 35 deletions(-)

-- 
paul moore
www.paul-moore.com

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Mon, 6 Apr 2015, Paul Moore wrote:

> Removed the patch, it should now just contain the five patches described at 
> the start, and shown again below.  It's based again the current security#next 
> branch so there should be no problems, at least there haven't been in my test 
> pulls.

Ok, I'll pull it on the weekend when I get back from PTO.


-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

On Wed, Apr 8, 2015 at 6:57 AM, James Morris <jmorris@namei.org> wrote:
> On Mon, 6 Apr 2015, Paul Moore wrote:
>
>> Removed the patch, it should now just contain the five patches described at
>> the start, and shown again below.  It's based again the current security#next
>> branch so there should be no problems, at least there haven't been in my test
>> pulls.
>
> Ok, I'll pull it on the weekend when I get back from PTO.

Okay, thanks.  When you get back I'd still be curious to hear how you
manage the security tree; my process works *ok* but I'm always looking
for new approaches that may work better.

-- 
paul moore
www.paul-moore.com

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Wed, 8 Apr 2015, Paul Moore wrote:

> On Wed, Apr 8, 2015 at 6:57 AM, James Morris <jmorris@namei.org> wrote:
> > On Mon, 6 Apr 2015, Paul Moore wrote:
> >
> >> Removed the patch, it should now just contain the five patches described at
> >> the start, and shown again below.  It's based again the current security#next
> >> branch so there should be no problems, at least there haven't been in my test
> >> pulls.
> >
> > Ok, I'll pull it on the weekend when I get back from PTO.
> 
> Okay, thanks.  When you get back I'd still be curious to hear how you
> manage the security tree; my process works *ok* but I'm always looking
> for new approaches that may work better.

Currently I merge my next branch with Linus at -rc1 or -rc2, after 
experimenting with other approaches.  I pull into that from security 
subsystems and push to Linus during the merge window.  Do you need any 
more info?  Not sure what else there is to add.

For urgent fixes, I branch from Linus current (e.g. for-linus) and use 
that to push to Linus. This is a volatile branch which should not be 
tracked.


-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

On Sun, Apr 12, 2015 at 9:46 PM, James Morris <jmorris@namei.org> wrote:
> On Wed, 8 Apr 2015, Paul Moore wrote:
>
>> On Wed, Apr 8, 2015 at 6:57 AM, James Morris <jmorris@namei.org> wrote:
>> > On Mon, 6 Apr 2015, Paul Moore wrote:
>> >
>> >> Removed the patch, it should now just contain the five patches described at
>> >> the start, and shown again below.  It's based again the current security#next
>> >> branch so there should be no problems, at least there haven't been in my test
>> >> pulls.
>> >
>> > Ok, I'll pull it on the weekend when I get back from PTO.
>>
>> Okay, thanks.  When you get back I'd still be curious to hear how you
>> manage the security tree; my process works *ok* but I'm always looking
>> for new approaches that may work better.
>
> Currently I merge my next branch with Linus at -rc1 or -rc2, after
> experimenting with other approaches.  I pull into that from security
> subsystems and push to Linus during the merge window.  Do you need any
> more info?  Not sure what else there is to add.
>
> For urgent fixes, I branch from Linus current (e.g. for-linus) and use
> that to push to Linus. This is a volatile branch which should not be
> tracked.

So no long running branches then?  You simply recreate your next
branch every release?

-- 
paul moore
www.paul-moore.com

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Thu, 23 Apr 2015, Paul Moore wrote:

> On Sun, Apr 12, 2015 at 9:46 PM, James Morris <jmorris@namei.org> wrote:
> > On Wed, 8 Apr 2015, Paul Moore wrote:
> >
> >> On Wed, Apr 8, 2015 at 6:57 AM, James Morris <jmorris@namei.org> wrote:
> >> > On Mon, 6 Apr 2015, Paul Moore wrote:
> >> >
> >> >> Removed the patch, it should now just contain the five patches described at
> >> >> the start, and shown again below.  It's based again the current security#next
> >> >> branch so there should be no problems, at least there haven't been in my test
> >> >> pulls.
> >> >
> >> > Ok, I'll pull it on the weekend when I get back from PTO.
> >>
> >> Okay, thanks.  When you get back I'd still be curious to hear how you
> >> manage the security tree; my process works *ok* but I'm always looking
> >> for new approaches that may work better.
> >
> > Currently I merge my next branch with Linus at -rc1 or -rc2, after
> > experimenting with other approaches.  I pull into that from security
> > subsystems and push to Linus during the merge window.  Do you need any
> > more info?  Not sure what else there is to add.
> >
> > For urgent fixes, I branch from Linus current (e.g. for-linus) and use
> > that to push to Linus. This is a volatile branch which should not be
> > tracked.
> 
> So no long running branches then?  You simply recreate your next
> branch every release?

The next branch is long running.


-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

On Thu, Apr 23, 2015 at 8:24 PM, James Morris <jmorris@namei.org> wrote:
> On Thu, 23 Apr 2015, Paul Moore wrote:
>
>> On Sun, Apr 12, 2015 at 9:46 PM, James Morris <jmorris@namei.org> wrote:
>> > On Wed, 8 Apr 2015, Paul Moore wrote:
>> >
>> >> On Wed, Apr 8, 2015 at 6:57 AM, James Morris <jmorris@namei.org> wrote:
>> >> > On Mon, 6 Apr 2015, Paul Moore wrote:
>> >> >
>> >> >> Removed the patch, it should now just contain the five patches described at
>> >> >> the start, and shown again below.  It's based again the current security#next
>> >> >> branch so there should be no problems, at least there haven't been in my test
>> >> >> pulls.
>> >> >
>> >> > Ok, I'll pull it on the weekend when I get back from PTO.
>> >>
>> >> Okay, thanks.  When you get back I'd still be curious to hear how you
>> >> manage the security tree; my process works *ok* but I'm always looking
>> >> for new approaches that may work better.
>> >
>> > Currently I merge my next branch with Linus at -rc1 or -rc2, after
>> > experimenting with other approaches.  I pull into that from security
>> > subsystems and push to Linus during the merge window.  Do you need any
>> > more info?  Not sure what else there is to add.
>> >
>> > For urgent fixes, I branch from Linus current (e.g. for-linus) and use
>> > that to push to Linus. This is a volatile branch which should not be
>> > tracked.
>>
>> So no long running branches then?  You simply recreate your next
>> branch every release?
>
> The next branch is long running.

I guess I misunderstood your merge with -rc1/-rc2 comment, I thought
you meant you rebased at each -rc1/-rc2.

-- 
paul moore
www.paul-moore.com

Re: [GIT PULL] SELinux patches for 4.1

[Casey Schaufler]

On 4/24/2015 7:53 AM, Paul Moore wrote:
> On Thu, Apr 23, 2015 at 8:24 PM, James Morris <jmorris@namei.org> wrote:
>> On Thu, 23 Apr 2015, Paul Moore wrote:
>>
>>> On Sun, Apr 12, 2015 at 9:46 PM, James Morris <jmorris@namei.org> wrote:
>>>> On Wed, 8 Apr 2015, Paul Moore wrote:
>>>>
>>>>> On Wed, Apr 8, 2015 at 6:57 AM, James Morris <jmorris@namei.org> wrote:
>>>>>> On Mon, 6 Apr 2015, Paul Moore wrote:
>>>>>>
>>>>>>> Removed the patch, it should now just contain the five patches described at
>>>>>>> the start, and shown again below.  It's based again the current security#next
>>>>>>> branch so there should be no problems, at least there haven't been in my test
>>>>>>> pulls.
>>>>>> Ok, I'll pull it on the weekend when I get back from PTO.
>>>>> Okay, thanks.  When you get back I'd still be curious to hear how you
>>>>> manage the security tree; my process works *ok* but I'm always looking
>>>>> for new approaches that may work better.
>>>> Currently I merge my next branch with Linus at -rc1 or -rc2, after
>>>> experimenting with other approaches.  I pull into that from security
>>>> subsystems and push to Linus during the merge window.  Do you need any
>>>> more info?  Not sure what else there is to add.
>>>>
>>>> For urgent fixes, I branch from Linus current (e.g. for-linus) and use
>>>> that to push to Linus. This is a volatile branch which should not be
>>>> tracked.
>>> So no long running branches then?  You simply recreate your next
>>> branch every release?
>> The next branch is long running.
> I guess I misunderstood your merge with -rc1/-rc2 comment, I thought
> you meant you rebased at each -rc1/-rc2.
>

James, do you suppose you could send an announcement when you
do your merge? That would make it easier on the sub-tree maintainers.
Just a quick "I merged the next branch to XXXX" to the LSM list.

Re: [GIT PULL] SELinux patches for 4.1

[Paul Moore]

On Fri, Apr 24, 2015 at 6:20 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> James, do you suppose you could send an announcement when you
> do your merge? That would make it easier on the sub-tree maintainers.
> Just a quick "I merged the next branch to XXXX" to the LSM list.

That would definitely make my life a little easier.

-- 
paul moore
www.paul-moore.com

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Fri, 24 Apr 2015, Paul Moore wrote:

> > The next branch is long running.
> 
> I guess I misunderstood your merge with -rc1/-rc2 comment, I thought
> you meant you rebased at each -rc1/-rc2.

Yep, it's a merge, not a rebase.


-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[James Morris]

On Sun, 26 Apr 2015, Paul Moore wrote:

> On Fri, Apr 24, 2015 at 6:20 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> > James, do you suppose you could send an announcement when you
> > do your merge? That would make it easier on the sub-tree maintainers.
> > Just a quick "I merged the next branch to XXXX" to the LSM list.
> 
> That would definitely make my life a little easier.

Ok, sure.

-- 
James Morris
<jmorris@namei.org>

Re: [GIT PULL] SELinux patches for 4.1

[Mimi Zohar]

On Mon, 2015-04-27 at 15:28 +1000, James Morris wrote:
> On Sun, 26 Apr 2015, Paul Moore wrote:
> 
> > On Fri, Apr 24, 2015 at 6:20 PM, Casey Schaufler <casey@schaufler-ca.com> wrote:
> > > James, do you suppose you could send an announcement when you
> > > do your merge? That would make it easier on the sub-tree maintainers.
> > > Just a quick "I merged the next branch to XXXX" to the LSM list.
> > 
> > That would definitely make my life a little easier.
> 
> Ok, sure.

After posting the integrity patches here, I tried applying them to
Linus' 4.1.0-rc1 branch to make sure they'll apply cleanly.  Looks like
commit c6f439d "VFS: security/: d_backing_inode() annotations" affects
all of the security subsystems.

Mimi

secilc bug

[Dominick Grift]

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

Today i hit an bug in secilc, when compiled by policy with some modules excluded.

My policy is rather complex, and so i find the issue hard to explain but i will try:

In my github.com/doverride/laptop policy (the auth.cil module to be precise) i have a auth_pam_config_object_type() macro that
essentially associates the calling type with the auth_pam_config_object_type type attribute, which in turn is associated with
the auth_object_type attribute that is used to grant auth_admin() access to all "auth object types"

The auth_pam_config_object_type() macro is called in various modules for various third party pam config files.

For example, xserver maintains /etc/pam.d/xserver, which is associated with xserver_pam_config_t, and xserver_pam_config_t is
associated with auth_pam_config_object_type.

This is just one example.

By excluding the xserver.cil module, the whole auth_pam_config_object_type, and all rules associated with it vanishes.
I noticed today that on a system where i excluded xserver.cil i no longer had access to /etc/security/access.conf (which is
associated with pam_config_t, and pam_config_t is associated with auth_pam_config_object_type)

By reincluding the xserver.cil module , the rules that allow auth_admin() to maintain auth_object_type files reappeared.

To reproduce:

clone my "laptop" policy and build it

use "sesearch -A -s auth_admin_subject_type | grep auth_object_type" to confirm that auth_admin_subject_type is allowed
to maintain file objects associated with auth_object_type

Now exclude the xserver.cil module

use above sesearch command again and notice how the rules granting auth_admin_subject_type access to maintain file objects
associated with auth_object_type have vanished.

P.S:
Another really strange thing i noticed is that i have a compiled policy with a bunch of modules excluded that is bigger than
a policy with little or no modules excluded.

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc bug

[Dominick Grift]

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

On Sat, May 02, 2015 at 05:02:59PM +0200, Dominick Grift wrote:
> Today i hit an bug in secilc, when compiled by policy with some modules excluded.

<snip>

I suspect the issue is something like the following:

There are currently no rules associated with the pam_auth_config_object_type type attribute thus it will be removed from the policy by secilc

However this may or may not change. I do have macros with rules assoc. with pam_auth_config_object_type, they are currently just not called by anything

In my policy, the pam_auth_config_object_type type attribute currently only acts as a bridge to auth_object_type type attribute 

Example: pam_config_t (and many other types) is/are assoc. with auth_pam_config_object_type, auth_pam_config_object_type is associated
with auth_object_type, and there are rules assoc. with auth_object_type

(for example: auth_admin_subject_type auth_object_type (all_file_objects (all_file_perms_except)))

The question remains, how does me exluding the xserver.cil affects all this. I actually commented out the only call to
the auth.cil module ( (call auth_pam_config_object_type (xserver_pam_config_t)) ) from the xserver module and it turns out to not
affect it. So it is not that macro call.

It may instead be another ordering issue...

E.g. excluding the xserver.cil module may mess up the ordering of the modules to process in such a way that this rule vanishes

Because that is what this issue boils down to: rules vanishing for no reason

I made a screencast that tries to explain the issue:

https://www.youtube.com/watch?v=XRp5z9aqLDo

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc bug

[James Carter]

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

On 05/03/2015 06:50 AM, Dominick Grift wrote:
> On Sat, May 02, 2015 at 05:02:59PM +0200, Dominick Grift wrote:
>> Today i hit an bug in secilc, when compiled by policy with some modules excluded.
>
> <snip>
>
> I suspect the issue is something like the following:
>
> There are currently no rules associated with the pam_auth_config_object_type type attribute thus it will be removed from the policy by secilc
>
> However this may or may not change. I do have macros with rules assoc. with pam_auth_config_object_type, they are currently just not called by anything
>
> In my policy, the pam_auth_config_object_type type attribute currently only acts as a bridge to auth_object_type type attribute
>
> Example: pam_config_t (and many other types) is/are assoc. with auth_pam_config_object_type, auth_pam_config_object_type is associated
> with auth_object_type, and there are rules assoc. with auth_object_type
>
> (for example: auth_admin_subject_type auth_object_type (all_file_objects (all_file_perms_except)))
>
> The question remains, how does me exluding the xserver.cil affects all this. I actually commented out the only call to
> the auth.cil module ( (call auth_pam_config_object_type (xserver_pam_config_t)) ) from the xserver module and it turns out to not
> affect it. So it is not that macro call.
>
> It may instead be another ordering issue...
>

There doesn't seem to be ordering issues related to typeattributeset statements. 
See attached test policy if you're interested.

> E.g. excluding the xserver.cil module may mess up the ordering of the modules to process in such a way that this rule vanishes
>
> Because that is what this issue boils down to: rules vanishing for no reason
>
> I made a screencast that tries to explain the issue:
>
> https://www.youtube.com/watch?v=XRp5z9aqLDo
>
>

I think that it would be more helpful to me if I could see the policy. Is it 
available anywhere? If not, could you send me at least the auth.cil and 
xserver.cil modules?


-- 
James Carter <jwcart2@tycho.nsa.gov>
National Security Agency

[-- Attachment #2: test.cil --]
[-- Type: application/vnd.ms-artgalry, Size: 1827 bytes --]

Re: secilc bug

[Steve Lawrence]

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

On 05/04/2015 11:19 AM, James Carter wrote:
> On 05/03/2015 06:50 AM, Dominick Grift wrote:
>> On Sat, May 02, 2015 at 05:02:59PM +0200, Dominick Grift wrote:
>>> Today i hit an bug in secilc, when compiled by policy with some
>>> modules excluded.
>>
>> <snip>
>>
>> I suspect the issue is something like the following:
>>
>> There are currently no rules associated with the
>> pam_auth_config_object_type type attribute thus it will be removed
>> from the policy by secilc
>>
>> However this may or may not change. I do have macros with rules assoc.
>> with pam_auth_config_object_type, they are currently just not called
>> by anything
>>
>> In my policy, the pam_auth_config_object_type type attribute currently
>> only acts as a bridge to auth_object_type type attribute
>>
>> Example: pam_config_t (and many other types) is/are assoc. with
>> auth_pam_config_object_type, auth_pam_config_object_type is associated
>> with auth_object_type, and there are rules assoc. with auth_object_type
>>
>> (for example: auth_admin_subject_type auth_object_type
>> (all_file_objects (all_file_perms_except)))
>>
>> The question remains, how does me exluding the xserver.cil affects all
>> this. I actually commented out the only call to
>> the auth.cil module ( (call auth_pam_config_object_type
>> (xserver_pam_config_t)) ) from the xserver module and it turns out to not
>> affect it. So it is not that macro call.
>>
>> It may instead be another ordering issue...
>>
> 
> There doesn't seem to be ordering issues related to typeattributeset
> statements. See attached test policy if you're interested.
> 
>> E.g. excluding the xserver.cil module may mess up the ordering of the
>> modules to process in such a way that this rule vanishes
>>
>> Because that is what this issue boils down to: rules vanishing for no
>> reason
>>
>> I made a screencast that tries to explain the issue:
>>
>> https://www.youtube.com/watch?v=XRp5z9aqLDo
>>
>>
> 
> I think that it would be more helpful to me if I could see the policy.
> Is it available anywhere? If not, could you send me at least the
> auth.cil and xserver.cil modules?
> 

I think this might be a reset issue, with classmappings or something
related to classmappings not getting reset/re-resolved correctly. I've
noticed that with xserver.cil removed, some optional fails and causes a
re-resolve. Then when writing to the binary, the allow rule mentioned
ends up with all perms being empty, and so the allow rule is never added.

Note I also needed to modify EXCLUDE to exclude a handful of files due
to dependencies with xserver. I've attached that file.

- Steve

[-- Attachment #2: EXCLUDE --]
[-- Type: text/plain, Size: 959 bytes --]

tests/
sources/modules/contrib/applications/setbacklight.cil
sources/modules/contrib/applications/b43fwcutter.cil
sources/modules/contrib/services/bluetooth.cil
sources/modules/contrib/system/myqemu.cil
sources/modules/contrib/system/tunctl.cil
sources/modules/contrib/system/bridgeutil.cil
sources/modules/contrib/applications/firefox.cil
sources/modules/contrib/applications/qiv.cil
sources/modules/contrib/applications/xpdf.cil
sources/modules/contrib/applications/xutil.cil
sources/modules/contrib/applications/dunst.cil
sources/modules/contrib/applications/xlock.cil
sources/modules/contrib/applications/xterm.cil
sources/modules/contrib/applications/xbindkeys.cil
sources/modules/contrib/applications/rp.cil
sources/modules/contrib/applications/dbuslaunch.cil
sources/modules/contrib/applications/ffmpeg.cil
sources/modules/contrib/applications/mplayer.cil
sources/modules/contrib/applications/cowsay.cil
sources/modules/contrib/applications/atspi2.cil

Re: secilc bug

[Dominick Grift]

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

On Mon, May 04, 2015 at 11:19:51AM -0400, James Carter wrote:
> 
> I think that it would be more helpful to me if I could see the policy. Is it
> available anywhere? If not, could you send me at least the auth.cil and
> xserver.cil modules?
> 

Sure, It is available at: http://www.github.com/doverride/laptop



[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc bug

[Dominick Grift]

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

On Mon, May 04, 2015 at 11:33:06AM -0400, Steve Lawrence wrote:
> 
> I think this might be a reset issue, with classmappings or something
> related to classmappings not getting reset/re-resolved correctly. I've
> noticed that with xserver.cil removed, some optional fails and causes a
> re-resolve. Then when writing to the binary, the allow rule mentioned
> ends up with all perms being empty, and so the allow rule is never added.
> 
> Note I also needed to modify EXCLUDE to exclude a handful of files due
> to dependencies with xserver. I've attached that file.
> 

Yes, indeed. My policy infrastructure support local changes though

One can create an EXCLUDE.local file in the root and in there add the modules one wishes to exclude

This file should not conflict with the "upstream" EXCLUDE file

So EXCLUDE is used by upstream and EXCLUDE.local is for local exclusions

Similarly seusers and seusers.local

Basically the repository has a local and upstream side, so that one can make local changes without breaking the repository by for example updating it with git pull

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc bug

[Dominick Grift]

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

On Mon, May 04, 2015 at 05:44:44PM +0200, Dominick Grift wrote:
> On Mon, May 04, 2015 at 11:33:06AM -0400, Steve Lawrence wrote:
> > 
> > I think this might be a reset issue, with classmappings or something
> > related to classmappings not getting reset/re-resolved correctly. I've
> > noticed that with xserver.cil removed, some optional fails and causes a
> > re-resolve. Then when writing to the binary, the allow rule mentioned
> > ends up with all perms being empty, and so the allow rule is never added.
> > 
> > Note I also needed to modify EXCLUDE to exclude a handful of files due
> > to dependencies with xserver. I've attached that file.
> > 
> 
> Yes, indeed. My policy infrastructure support local changes though
> 
> One can create an EXCLUDE.local file in the root and in there add the modules one wishes to exclude
> 
> This file should not conflict with the "upstream" EXCLUDE file
> 
> So EXCLUDE is used by upstream and EXCLUDE.local is for local exclusions
> 
> Similarly seusers and seusers.local
> 
> Basically the repository has a local and upstream side, so that one can make local changes without breaking the repository by for example updating it with git pull

Running ./laptop --help  explains the options a bit

-- 
02DFF788
4D30 903A 1CF3 B756 FB48  1514 3148 83A2 02DF F788
http://keys.gnupg.net/pks/lookup?op=vindex&search=0x314883A202DFF788
Dominick Grift

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]

Re: secilc bug

[Dominick Grift]

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

On Sat, May 02, 2015 at 05:02:59PM +0200, Dominick Grift wrote:
> Today i hit an bug in secilc, when compiled by policy with some modules excluded.
> 
> My policy is rather complex, and so i find the issue hard to explain but i will try:
> 
> In my github.com/doverride/laptop policy (the auth.cil module to be precise) i have a auth_pam_config_object_type() macro that
> essentially associates the calling type with the auth_pam_config_object_type type attribute, which in turn is associated with
> the auth_object_type attribute that is used to grant auth_admin() access to all "auth object types"
> 
> The auth_pam_config_object_type() macro is called in various modules for various third party pam config files.
> 
> For example, xserver maintains /etc/pam.d/xserver, which is associated with xserver_pam_config_t, and xserver_pam_config_t is
> associated with auth_pam_config_object_type.
> 
> This is just one example.
> 
> By excluding the xserver.cil module, the whole auth_pam_config_object_type, and all rules associated with it vanishes.
> I noticed today that on a system where i excluded xserver.cil i no longer had access to /etc/security/access.conf (which is
> associated with pam_config_t, and pam_config_t is associated with auth_pam_config_object_type)
> 
> By reincluding the xserver.cil module , the rules that allow auth_admin() to maintain auth_object_type files reappeared.
> 
> To reproduce:
> 
> clone my "laptop" policy and build it
> 
> use "sesearch -A -s auth_admin_subject_type | grep auth_object_type" to confirm that auth_admin_subject_type is allowed
> to maintain file objects associated with auth_object_type
> 
> Now exclude the xserver.cil module
> 
> use above sesearch command again and notice how the rules granting auth_admin_subject_type access to maintain file objects
> associated with auth_object_type have vanished.
> 
> P.S:
> Another really strange thing i noticed is that i have a compiled policy with a bunch of modules excluded that is bigger than
> a policy with little or no modules excluded.
> 


I want to retract this. This was most likely a parens issue to begin with. Today i hit a similar issue and i decided to dig a little deeper.
Granted the issue i hit today was much simpler to track down.

Anyhow it turned out to be a misplaced parens which resulted in secilc removing a lot of policy that it thought was in one optional block.

in reality they were many optional blocks but the first one wasnt closed properly!

Yes, the secilc warning about "open without close" or "close without open" are annoying. but take my word for it.
its much better to have secilc identify these issues then to have it not identify them and then when you decide to exclude a module
a whole load of policy gets removed because secilc thought it was part of the single block!

anyhow sorry for thinking this was a bug in secilc. it was my mistake. in my defense though: my policy is pretty complex and sometimes its not easy to identify the issue. Also parens arent that friendly to humans...

[-- Attachment #2: Type: application/pgp-signature, Size: 648 bytes --]