Re: [PATCH 00/12] Add kdbus implementation

[Karol Lewandowski <k.lewandowsk@samsung.com>]

On 2014-10-30 21:24, Greg Kroah-Hartman wrote:
> On Thu, Oct 30, 2014 at 08:55:56PM +0100, Karol Lewandowski wrote:
>> On 2014-10-30 15:47, Greg Kroah-Hartman wrote:
>>> On Thu, Oct 30, 2014 at 11:44:39AM +0100, Karol Lewandowski wrote:
>>>> [ Sorry for breaking thread and resend - gmane rejected my original message
>>>>   due to too long list of recipients... ]
>>>>
>>>> On 2014-10-30 00:40, Greg Kroah-Hartman wrote:
>>>>
>>>>> There is a 1815 line documentation file in this series, so we aren't
>>>>> trying to not provide this type of information here at all.  But yes,
>>>>> more background, about why this can't be done in userspace (zero copy,
>>>>> less context switches, proper credential passing, timestamping, availble
>>>>> at early-boot, LSM hooks for security models to tie into
>>>>
>>>> While you're at it... I did some work on proof-of-concept LSM patches for
>>>> kdbus some time ago, see [1][2].  Currently, these are completely of date.
>>>>
>>>>  [1] https://github.com/lmctl/linux/commits/kdbus-lsm-v4.for-systemd-v212
>>>>  [2] https://github.com/lmctl/kdbus/commit/aa0885489d19be92fa41c6f0a71df28763228a40
>>>>
>>>> May I ask if you guys have your own plan for LSM or maybe it would be
>>>> worth to resurrect [1]?
>>>
>>> The core calls are already mediated by LSM today, right?  We don't want
>>> anyone to be parsing the data stream through an LSM, that idea got
>>> rejected a long time ago as something that is really not a good idea.
>>
>> Parsing data is out of question, of course, but this is not what we were
>> proposing.
> 
> Glad to hear it :)
> 
>>> Other than that, I don't know exactly what your patches do, or why they
>>> are needed, care to go into details?
>>
>> Patches in question were supposed to add few hooks for kdbus-specific
>> operations that doesn't seem to have compatible semantics with hooks
>> currently available in LSM.
>>
>> kdbus' bus introduces quite a few new concepts that we wanted to be able
>> to limit based on MAC label/context, eg.
>>
>>  - check flags at HELO stage (say disallow fd passing),
>>
>>  - restrict ability to acquire name to certain subjects (for system bus),
>>
>>  - disallow creation of new buses,
>>
>>  - limit scope of broadcasts,
>>
>>  - etc.
> 
> Nice list.
> 
>> Please take a look at hook list - I think most of names are self-explanatory:
>>
>>   https://github.com/lmctl/linux/blob/a9fe4c33b6e5ab25a243e0590df406aabb6add12/include/linux/security.h#L1874
>>
>> kdbus modifications were pretty light - with most visible change being
>> addition of opaque security pointer to kdbus_bus and similar structs.
> 
> That looks very reasonable, care to make it up into a patch I can add to
> the end of this series so it's easy to review and possibly submit as
> part of it?

I'll do my best to prepare something suitable for review, but I'm
not sure it can/should be part of next patch set.

As Paul wrote - discussion about hooks hasn't really ended up with
satisfactory conclusion but just faded away.  kdbus own policy engine
has been  rewritten since I last touched it so I'm not sure what part
are still applicable.

(Unfortunately, I'll be traveling from monday and likely to be offline
for a week or two...)

Thanks
-- 
Karol Lewandowski, Samsung R&D Institute Poland