Adding support for SE-Linux security
in [PgSql]
|
From: Robert Haas on 8 Dec 2009 12:36 On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers <csellers(a)tresys.com> wrote: > On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl(a)tycho.nsa.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(a)tycho.nsa.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(a)momjian.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Tom Lane on 8 Dec 2009 13:50 Robert Haas <robertmhaas(a)gmail.com> writes: > 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. I don't think that it's about SELinux. The real issue here is that KaiGai-san is about a mile out in front of the PG hackers community in terms of his ambitions for the scope of what can be controlled by security policy. If the patch were only doing what the community has actually agreed to, there would be little need for it to touch anything but the aclcheck functions. Now I recognize that a large part of the potential attraction in this for the security community is exactly the idea of having fine-grain security control. But if you ever want anything significantly different from SQL-standard permission mechanisms, there's going to have to be a whole lot more work done. Basically, nobody in the PG community has got any confidence either in the overall design or the implementation details for locking things down that aren't already controlled by SQL permission mechanisms. regards, tom lane -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Robert Haas on 8 Dec 2009 14:22 On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > Robert Haas <robertmhaas(a)gmail.com> writes: >> 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. > > I don't think that it's about SELinux. The real issue here is that > KaiGai-san is about a mile out in front of the PG hackers community > in terms of his ambitions for the scope of what can be controlled by > security policy. If the patch were only doing what the community has > actually agreed to, there would be little need for it to touch anything > but the aclcheck functions. > > Now I recognize that a large part of the potential attraction in this > for the security community is exactly the idea of having fine-grain > security control. But if you ever want anything significantly different > from SQL-standard permission mechanisms, there's going to have to be a > whole lot more work done. Basically, nobody in the PG community has got > any confidence either in the overall design or the implementation > details for locking things down that aren't already controlled by SQL > permission mechanisms. I think that's basically right. Further, I think this is basically a resource issue. If you were inclined to spend a large amount of your time on this problem, you could either gain confidence in the present design and implementation or come up with a new one in which you did have confidence. But it doesn't seem important enough to you (or your employer) for the amount of time it would take, so you're not. I think there are other committers and community members in a similar situation - basically all of them. ....Robert -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: Chad Sellers on 8 Dec 2009 14:24 On 12/8/09 12:36 PM, "Robert Haas" <robertmhaas(a)gmail.com> wrote: > On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers <csellers(a)tresys.com> wrote: >> On 12/8/09 11:51 AM, "David P. Quigley" <dpquigl(a)tycho.nsa.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(a)tycho.nsa.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(a)momjian.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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
From: "David P. Quigley" on 8 Dec 2009 14:50
On Tue, 2009-12-08 at 14:22 -0500, Robert Haas wrote: > On Tue, Dec 8, 2009 at 1:50 PM, Tom Lane <tgl(a)sss.pgh.pa.us> wrote: > > Robert Haas <robertmhaas(a)gmail.com> writes: > >> 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. > > > > I don't think that it's about SELinux. The real issue here is that > > KaiGai-san is about a mile out in front of the PG hackers community > > in terms of his ambitions for the scope of what can be controlled by > > security policy. If the patch were only doing what the community has > > actually agreed to, there would be little need for it to touch anything > > but the aclcheck functions. > > > > Now I recognize that a large part of the potential attraction in this > > for the security community is exactly the idea of having fine-grain > > security control. But if you ever want anything significantly different > > from SQL-standard permission mechanisms, there's going to have to be a > > whole lot more work done. Basically, nobody in the PG community has got > > any confidence either in the overall design or the implementation > > details for locking things down that aren't already controlled by SQL > > permission mechanisms. > > I think that's basically right. Further, I think this is basically a > resource issue. If you were inclined to spend a large amount of your > time on this problem, you could either gain confidence in the present > design and implementation or come up with a new one in which you did > have confidence. But it doesn't seem important enough to you (or your > employer) for the amount of time it would take, so you're not. I > think there are other committers and community members in a similar > situation - basically all of them. > > ...Robert > I have to agree with Chad (downthread) that I don't see much in KaiGai's hook patch that prevents its use by other security models. I will say though one thing that might have been done wrong was with how it was presented. In actuality his patch set is two projects (at least). The first is the framework. So I think the goal should have been to get the framework integrated first and then work on the SELinux module after that. The framework patch alone consists of at least 4 sets of logical changes that could have been separated to make review easier. Once the framework was in, work could be done to get the SELinux module in while reducing overhead from the case where no module is loaded. So with regard to confidence in the design I think that part of the reason for the skepticism in the fact that it was such a large code drop. Even the separated parts were very large. I think if the framework patches are broken up more logically and in a way that is easier to discuss then that might help the community get a grasp on what it is trying to accomplish. In terms of documentation I was reading through the wiki at sepgsql.googlecode.com and aside from some wordsmithing/grammar things it is pretty solid with describing what it is trying to accomplish. One problem that I see is that at first glance it does appear to be very SELinux centric. It describes access based on types and SELinux contexts which is understandable based on the fact that it describes the framework and the module. Something to note is that the documentation describes an object model for the program. I think that would be a good place to focus the discussion with respect to a framework if we decide to pursue it. Dave -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |