Re: Adding support for SE-Linux security

On 12/8/09 12:36 PM, "Robert Haas" <robertmhaas(at)gmail(dot)com> wrote:

> 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.

Sorry, my mistake. This mailing list moves pretty quick so it's hard to
catch up with everything.

> 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.

So, a generalized framework is nice in that it supports multiple models, but
it does bring with it an additional maintenance burden. I'm sure that's been
discussed at length already.

I will say that it's almost impossible to place hooks properly for imaginary
users. So, if you create a framework, it's probably just a placeholder with
hooks for the one user (SEPostgreSQL) that will later have to be
modified/augmented to support additional users. This is how things went with
LSM. LSM was added to Linux and created with input from several users
(SELinux folks, Immunix (later AppArmor) folks, and others) and still took
years before most of the other mechanisms could use it without extra
patches. If you're trying to build a generalized access control framework
with only one user, it will have to change the day user 2 comes along.

> 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.

That's not surprising. If you look at the experience from adding access
control hooks to the Linux kernel (both the initial patchset that added
SELinux hooks directly, and the LSM hooks) as well as the XACE hooks added
to X.org, you'll find similar experiences.

> 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?
>
My guess would be most of them are applicable to most sorts of label-based
MAC. While LSM needed work to be used by the path-based systems out there,
SMACK (which uses labels of a different ilk) required very few (maybe no?)
changes to LSM to work. Looking through the hooks, I see very little that
doesn't look like it would not work for some other label-based systems
(though possibly not all).

Thanks,
Chad Sellers