| Main Archive Page > Month Archives > selinux archives |
RE: [patch 1/3] libsemanage: genhomedircon replacement
From: Joshua Brindle <jbrindle_at_nospam>Date: Thu Jun 21 2007 - 18:25:07 GMT
To: "Karl MacMillan" <kmacmillan@mentalrootkit.com>
Karl MacMillan wrote:
> 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.
>
Not to mention running a python interpreter from a library is pretty lame. How is this any worse than the other craziness that is libsemanage?
>> 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.
We already have a facility to run external apps that can do that. In semanage.conf just do:
[verify module]
path=/some/path/to/checker
[end]
Which has nothing to do with genhomedircon, genhomedircon is mutating the store, we should not be providing a facility to let random programs mutate the store arbitrarilly. -- 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.