All of lore.kernel.org
 help / color / mirror / Atom feed
From: Eric Paris <eparis@redhat.com>
To: Stephen Smalley <sds@tycho.nsa.gov>
Cc: selinux@tycho.nsa.gov, jmorris@namei.org, kaigai@kaigai.gr.jp,
	method@manicmethod.com
Subject: Re: [PATCH 1/2] SELinux: allow userspace to read policy back out of the kernel
Date: Wed, 13 Oct 2010 15:15:42 -0400	[thread overview]
Message-ID: <1286997342.2614.35.camel@localhost.localdomain> (raw)
In-Reply-To: <1286979463.2614.31.camel@localhost.localdomain>

On Wed, 2010-10-13 at 10:17 -0400, Eric Paris wrote:
> On Wed, 2010-10-13 at 09:20 -0400, Eric Paris wrote:
> > On Tue, 2010-07-27 at 14:39 -0400, Stephen Smalley wrote:
> 
> > > Yes, I'd be in favor of that.  Just define the rangetr_cmp function in
> > > the kernel to truly order the entries at load time and sort them in the
> > > same manner in libsepol before writing.
> > 
> > Started working on this yesterday and still don't have a bit for bit
> > identical policy.
> 
> [snip]
> 
> > These two show that the files are now identical outside of the avtab
> > entries.  Now I'm trying to figure out why the avtab entries are not the
> > same.  Anyone have guesses off the top of their head?
> 
> My first thought is that the avtab was allocated in expand_avtab() for
> the policy.25 and thus was done with an expected # of rules equal to
> MAX_AVTAB_SIZE, whereas the kernel builds a 'correctly' sized avtab
> since it knows the correct number of rules.  If this is the case it
> explains how things would get put in different buckets and we end up
> with the same policy, but different ordering.
> 
> If this is the case (which seems likely) I'm wondering the best way to
> fix this.  I don't really want to have to rebuild the userspace avtable
> a second time just to get final ordering (as if userspace wasn't slow
> enough) but we can't size the avtab correctly during expand either...

Easy enough to fix.  The kernel has MAX_HASH_BUCKETS = 1<<10 (I think it
was intended to be 11) whereas usespace was doing MAX_HASH_BUCKETS =
1<<12 (again I think the intention was 13)

But maxing userspace out at 10 like the kernel I now have a bit for bit
exact replica coming back out of the kernel with my policydb write
patch.  I'll work on cleaning everything up (including the
MAX_HASH_BUCKETS thing I don't quite understand) and post some patches.

-Eric


--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

  reply	other threads:[~2010-10-13 19:15 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-26 19:34 [PATCH 1/2] SELinux: allow userspace to read policy back out of the kernel Eric Paris
2010-07-26 19:34 ` [PATCH 2/2] selinux: implement mmap on /selinux/policy Eric Paris
2010-07-27 16:47   ` Stephen Smalley
2010-07-27 16:50     ` Eric Paris
2010-07-27 18:36   ` Stephen Smalley
2010-07-27 18:51     ` Eric Paris
2010-07-27 19:09       ` Stephen Smalley
2010-07-27 19:16         ` Eric Paris
2010-07-27 19:20           ` Stephen Smalley
2010-07-27 19:24             ` Eric Paris
2010-07-27 19:28               ` Stephen Smalley
2010-07-27 20:24                 ` Eric Paris
2010-07-29 12:50                   ` Stephen Smalley
2010-07-29 17:58                     ` Eric Paris
2010-07-26 20:48 ` [PATCH 1/2] SELinux: allow userspace to read policy back out of the kernel Stephen Smalley
2010-07-27 18:11   ` Eric Paris
2010-07-27 18:39     ` Stephen Smalley
2010-10-13 13:20       ` Eric Paris
2010-10-13 14:17         ` Eric Paris
2010-10-13 19:15           ` Eric Paris [this message]
2010-07-27 18:31 ` Stephen Smalley

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1286997342.2614.35.camel@localhost.localdomain \
    --to=eparis@redhat.com \
    --cc=jmorris@namei.org \
    --cc=kaigai@kaigai.gr.jp \
    --cc=method@manicmethod.com \
    --cc=sds@tycho.nsa.gov \
    --cc=selinux@tycho.nsa.gov \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.