Adding support for SE-Linux security
in [PgSql]
|
From: "David P. Quigley" on 8 Dec 2009 10:07 On Mon, 2009-12-07 at 22:25 -0500, Greg Smith wrote: > David P. Quigley wrote: > > Not to start a flame war here about access control models but you gave 3 > > different examples one of which I don't think has any means to do > > anything productive here. > You won't be starting a flame war for the same reason some of the > community members are so concerned about this patch. There aren't enough > people familiar with this part of the security field within our database > developer community to even be able to answer fairly basic questions > like the one you just clarified. If you can help bring more qualified > reviewers to bear on that, it would be extremely helpful. I even tried > to organize a meetup between PostgreSQL hackers working in this area and > the security people I knew around here (Baltimore/DC) last year, but > just couldn't find any interested enough to show. Other than a brief > visit on this list from some of the Tresys guys, we haven't seen much > input here beyond that offered by the patch author, who's obviously > qualified but at the end of the day is still only one opinion. He's also > not in a good position to tell other people their ideas are misinformed > either. > I can't make any guarantees on who I can drag to a meeting but if you wanted to try to organize another meeting between the Postgres people and some of us I can try to organize it on our end. One of my coworkers that does a lot of commenting on stuff like this is on leave at the moment but when he gets back I'll discuss it with him. I'll also talk with some of the other people in the area on our end to see what I can arrange. If you have any questions in the meantime feel free to ask. If there are any specific parts of the patch that you'd like discussed I can do that as well. I do have to agree though that I'd rather see KaiGai's original security plugin framework go in and then merge a particular security module after that.From what I see it would require at least the hook framework and the label storage mechanism. I feel bad saying that knowing the KaiGai spent a lot of time ripping all of that out. However if you are concerned about supporting more than just SELinux as a MAC model then the plugin framework he originally proposed is the better solution. I'd be willing to take a look at the framework and see if it really is SELinux centric. If it is we can figure out if there is a way to accomodate something like SMACK and FMAC. I'd like to hear from someone with more extensive experience with Solaris Trusted Extensions about how TX would make use of this. I have a feeling it would be similar to the way it deals with NFS which is by having the process exist in the global zone as a privileged process and then multi-plexes it to the remaining zones. That way their getpeercon would get a label derived from the zone. 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
From: Robert Haas on 8 Dec 2009 10:19 On Tue, Dec 8, 2009 at 10:07 AM, David P. Quigley <dpquigl(a)tycho.nsa.gov> wrote: > I'd be willing to take a look at the framework and see if it really is > SELinux centric. If it is we can figure out if there is a way to > accomodate something like SMACK and FMAC. I'd like to hear from someone > with more extensive experience with Solaris Trusted Extensions about how > TX would make use of this. I have a feeling it would be similar to the > way it deals with NFS which is by having the process exist in the global > zone as a privileged process and then multi-plexes it to the remaining > zones. That way their getpeercon would get a label derived from the > zone. Well, the old patches should still be available in the mailing list archives. Maybe going back and looking at that code would be a good place to start. The non-ripped-out code has been cleaned up a lot since then, but at least it's a place to start. ....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: Robert Haas on 8 Dec 2009 11:48 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 -- 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 11:51 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 -- 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 12:16
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 -- Sent via pgsql-hackers mailing list (pgsql-hackers(a)postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers |