| Main Archive Page > Month Archives > selinux archives |
RE: [patch 1/3] libsemanage: genhomedircon replacement
From: Karl MacMillan <kmacmillan_at_nospam>Date: Thu Jun 21 2007 - 18:18:18 GMT
To: Joshua Brindle <jbrindle@tresys.com>
On Thu, 2007-06-21 at 14:09 -0400, Joshua Brindle wrote:
> Karl MacMillan wrote:
> > On Thu, 2007-06-21 at 12:49 -0400, Joshua Brindle wrote:
> >> Karl MacMillan wrote:
> >>> On Tue, 2007-06-19 at 11:09 -0400, Joshua Brindle wrote:
> >>>> Karl MacMillan wrote:
> >>>>> On Fri, 2007-05-25 at 13:06 -0400, Joshua Brindle wrote:
> >>>>>> Karl MacMillan wrote:
> >>>>>>>> If you would like to move the list types out of policyrep and
> >>>>>>>> into trunk, I'll be happy to use it. Otherwise it is out of
> >>>>>>>> the scope of this patch.
> >>>>>>>>
> >>>>>>> Please rebase against the policyrep branch - we can then
> >>>>>>> consider merging the list types and this patch to trunk if
> >>>>>>> desired. I will NACK this patch if it contains the
> > additional list types.
> >>>>>> There aren't additional list types because there aren't any in
> >>>>>> trunk. This has nothing to do with policyrep and doesn't break
> >>>>>> ABI compatibility and should be in trunk. I hate this idea of
> >>>>>> pushing everything into policyrep because its going to make it
> >>>>>> that much harder to get good testing done and the source of bugs
> >>>>>> will be harder to track down.
> >>>>>>
> >>>>>
> >>>>> Ok.
> >>>>>
> >>>>>> If you are so insistent on using the list types in policyrep why
> >>>>>> not port them to trunk so we can use them?
> >>>>>
> >>>>> That option is fine with me (and was one of my suggestions),
> >>>>> though I don't have time to do the port right now. Can you or Mark
> >>>>> send a patch pulling over the iterators and list?
> >>>>
> >>>> I'm going to bring this back up because I think this patch is
> >>>> important to get into upstream as a first step toward generic
> >>>> label generation.
> >>>>
> >>>
> >>> Can you tell me a little more about what you are thinking with this?
> >>>
> >
> > ??
> >
>
> We need labels for various object managers (like policy server)
> generated per user. For example, if you look back at the PoC apache
> metapolicy you'll see some hardcoded labels like user_apache_types_t and
> so on, these need to be generated for each user.
>
>
> >>>> Since we aren't using the policyrep branch anymore and libpolicyrep
> >>>> is going to be in c++ do you still have reservations against this
> >>>> patch?
> >>>>
> >>>
> >>> I'm still convinced about the maintenance long term and potential
> >>> for errors. Have all of the implementation issues that James brought
> >>> up been resolved? Remind me why this is better in C than in an
> >>> external Python helper.
> >>>
> >>
> >> Its very hacky, we have to close the current transaction (from within
> >> the library) so that genhomedircon can connect and get a read lock on
> >> the newly created active store and then it modifies the files outside
> >> of the module store, non-ideal in almost every way.
> >>
> >
> > Why does it need to get the read lock - why can't it be
> > changed to take the sandbox location and work on that
> > directly? Fixing that might be better long term as it seems
> > advantageous to allow helper programs in general (for
> > separation and least-privilege).
> >
>
> Work directly on the module store? The module store is a private
> resource of libsemanage, applications should not modify it directly
> outside of libsemanage.
genhomedircon is part of libsemanage - it just runs in a separate process. IOW it is just an implementation detail.
> The least-priv argument is nonsense since
> semodule/semanage/setsebool always have to be able to generate
> everything in the module store and copy them all out to the filesystem,
> making genhomedircon separate serves no purpose in that regard.
Think about a process to verify untrusted data (like modules) - it would be helpful to allow a separate process to examine that data. Yes things like semodule will have full access but allowing a lower-privileged process to handle some parts is desirable in my opinion.
Karl -- 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.