Re: Adding support for SE-Linux security

On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers <csellers(at)tresys(dot)com> wrote:
> On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl(at)tycho(dot)nsa(dot)gov> wrote:
>
>> On Tue, 2009-12-08 at 11:48 -0500, Robert Haas wrote:
>>> On Tue, Dec 8, 2009 at 10:51 AM, David P. Quigley <dpquigl(at)tycho(dot)nsa(dot)gov>
>>> wrote:
>>>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote:
>>>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian <bruce(at)momjian(dot)us> wrote:
>>>>>> As Alvaro mentioned, the original patch used ACE but it added too much
>>>>>> code so the community requested its removal from the patch.  It could be
>>>>>> re-added if we have a need.
>>>>>
>>>>> Well, there's no point in putting that framework back in unless we can
>>>>> make it sufficiently general that it could be used to serve the needs
>>>>> of more than one security model.  And so far, the signs have not been
>>>>> promising.  David Quigley suggests downthread that making a truly
>>>>> general model isn't really possible, and he may be right, or not.  I
>>>>> was just mentioning that it's an angle I have been thinking about
>>>>> investigating, but it may be a dead end.
>>>>>
>>>>> The real issue is making the code committable, and then maintaining
>>>>> it, as Tom rightly says, forever.  We've got to make sure that we're
>>>>> willing to take that on before we do it, and I don't think it's a
>>>>> small task.  It isn't so much whether we want the feature as whether
>>>>> the level of effort is proportionate to the benefit.
>>>>>
>>>>> ...Robert
>>>>>
>>>>
>>>> So the issue with generality is that path name based MAC has a different
>>>> set of requirements than label based does. If you want to acomodate
>>>> several types of label based MAC models then a framework can be
>>>> developed for that similar to the one in the Linux Kernel. I asked
>>>> around after I sent the email yesterday and from what I understand
>>>> AppArmor does not have the concept of a userspace object manager so I
>>>> don't know what they'd do in this area. I'm sure they could come up with
>>>> a scheme to write policy for the database but I don't know how useful it
>>>> would be.
>>>>
>>>> If you look at the LSM framework in the Linux Kernel recently there have
>>>> been hooks added to accomodate path based MAC systems so it can be done
>>>> but adds another set of hooks. The important goal here though in
>>>> designing a framework is to make sure that you have a comprehensive list
>>>> of the objects you want to mediate and make sure you put the proper
>>>> enforcement points in. Someone may come along later and want to mediate
>>>> a new object or some new functionality may come along that introduces a
>>>> new object so a hook may then need to be added. Something to realize as
>>>> well is that a security model may not want to implement all of the hooks
>>>> and it doesn't have to. In the case of no module being loaded or someone
>>>> not wanting the loadable security module framework I'm sure we can
>>>> provide an option to reduce overhead or compile the framework out
>>>> completely.
>>>>
>>>> I'll take a look at his patches for the framework that KaiGai originally
>>>> proposed.
>>>
>>> It sounds like the pathname-based schemes are not really designed to
>>> work inside of a database anyway, so my first thought is we shouldn't
>>> worry about them.  The label-based schemes are by their nature
>>> designed to apply in an arbitrary context being applied to arbitrary
>>> objects.
>>>
>>> ...Robert
>>
>>
>> So I was reading through a set of slides that KaiGai has and he
>> mentioned a May commitfest link and I looked for the comments related to
>> his PGACE patches. I've been crawling through the commitfest paces so I
>> can figure out what the latest version of the pgace patch is. Does
>> anyone know when the patch was reduced to what it is today?
>>
>> Dave
>>
> I'm another SELinux developer and I'd like to help out where I can here. I'm
> a bit confused by this discussion of PGACE. I thought the postgresql
> community agreed that they wanted this removed in order to make the patch
> size smaller. Has that changed? Is the increase in patch size now
> acceptable? Sorry if I'm joining the conversation late.
>
> Thanks,
> Chad Sellers

Nothing's been decided. We're just trying to figure out the best way
to tackle the problem. I think the main question here is who if
anyone from among the committers is willing to put in the time and
effort to maintain this feature over the short and long haul, but
that's sort of an internal project issue. I was just thinking out
loud about whether it was possible and/or desirable to try to
modularize this a bit so that it could be used for more than just
SE-Linux. Obviously, the labeling stuff could be generalize to
accomodate a label from an arbitrary security system, but that's only
a small piece of the problem.

One of the major and fundamental stumbling blocks we've run into is
that every solution we've looked at so far seems to involve adding
SE-Linux-specific checks in many places in the code. It would be nice
if it were possible to use the exist permissions-checking functions
and have them check a few more things while they're at it, but it's
looking like that won't be feasible, or at least no one's come up with
a plausible design yet. Consequently there are checks spread
throughout the code, which definitely complicates both validation and
maintenance. One question I have is - are the places where those
checks are placed specific to SE-Linux, or would they be applicable to
any sort of label-based MAC?

...Robert