Re: [HACKERS] Adding support for SE-Linux security
On 12/8/09 11:51 AM, David P. Quigley dpqu...@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 dpqu...@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 br...@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@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] Adding support for SE-Linux security
On 12/8/09 12:36 PM, Robert Haas robertmh...@gmail.com wrote: On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers csell...@tresys.com wrote: On 12/8/09 11:51 AM, David P. Quigley dpqu...@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 dpqu...@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 br...@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
Re: [HACKERS] How to get SE-PostgreSQL acceptable
On 1/30/09 5:43 PM, Josh Berkus j...@agliodbs.com wrote: Joshua, Kohei-san, So, for 8.4: *if* we included in 8.4 a version of SEPostgres with all features *except* row-level security, would it still be useful to the SELinux community? Yes, it's definitely still useful. While many of the use cases we've wanted this for require row-level access control, there have been several that did not. It is definitely still useful, especially if it is a path toward row-level access control in a later release. Chad -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On 1/27/09 4:40 PM, Ron Mayer rm...@cheapcomplexdevices.com wrote: Joshua Brindle wrote: FWIW, as you know, sepostgresql is already included in Fedora. You can continue shipping it as a seperate RPM set. That is non-ideal. Getting the capability in to the standard database shipped with RHEL is very important to me and my customers. Could you speak - even in general terms - about who your customers are and what kinds of needs (is row-level acls the most important to them? mandantory access control at the table level? both?) they have? I'll speak to this a bit (Josh is also a Tresys employee). I can't say who my customers are, but I can speak to their needs. They really need row-level mandatory access controls (so both). I'll give a few examples that will hopefully help here. 1) One customer had several networks, each with a different classification. When a user needed to find anything, it was very painful as they would have to log into each network one at a time to search for anything. What they wanted to do was have a trusted database with a combined index of all the networks. They wanted to be able to write a flexible policy that could grant access to individual entries in the database based on what network the request came from in addition to the security clearance of the user requesting data. 2) Another example that we've been asked for repeatedly but had to turn away as the capability did not yet exist is a trusted LAMP/LAPP stack (Note that KaiGai is also working on the apache portion of this to provide a complete trusted LAPP stack). Under this model, individual web scripts can be run with a specific type. Combined with an SE-PostgreSQL policy, this gives the ability to restrict what a specific script can access. Additionally, as SE-PostgreSQL ties back in to the operating system mandatory access control mechanism, we can tie the type of the script back to the type of the actual user making the request. Coupled with labeled IPSec, this means we can control access to data in the database based on the clearance or role (or anything else you want to represent in their type) of the user on their end system. 3) A customer wanted to implement an approval process that required several steps. Without SE-PostgreSQL, we were forced to implement this by making lots of copies. Stage 1 would approve the package and copy it into Stage 2's inbox. We would grant each stage write access to the next stage's inbox in order to enforce information flow. This was very expensive, and didn't scale well. With SE-PostgreSQL, we could leave the data where it was and simply relabel the row(s). Each stage would be granted the ability to relabel from its type to the type of the next stage. No copies are necessary. I hope those help. I realize that many of you may not be used to dealing with customers who have such stringent security requirements, but if SE-PostgreSQL gets merged, that could change. Thanks, Chad Sellers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On 1/27/09 6:57 PM, Greg Smith gsm...@gregsmith.com wrote: On Tue, 27 Jan 2009, Chad Sellers wrote: I'll speak to this a bit (Josh is also a Tresys employee). I can't say who my customers are, but I can speak to their needs. They really need row-level mandatory access controls (so both). From the perspective of what this would buy as far as this feature being a PostgreSQL advocacy point, one of the questions Tom asked about a bit upthread is still a bit hazy here. There are commercial database offerings selling into the trusted space already. While the use-cases you describe make perfect sense, I don't think it's clear to everyone yet if there's a unique draw to a PostgreSQL + selinux solution that the class of customers you're talking about would prefer it to purchasing one of those products. Is the cost savings the main driver here, or is there something else about a secure LAPP stack that makes it particularly compelling? Cost savings may be a driver, but it's certainly not the main driver. A problem with the current systems (e.g. Oracle) is that they largely operate in their own world. Oracle Label Security labels do not extend outside the database to the rest of the system, which makes it impossible to build certain things. For instance, you can't really build a trusted LAPP stack. With SE-PostgreSQL, the label used for access control is bound by the kernel and used by it and the other components of the stack (apache, PostgreSQL). We can even extend all the way to the end system using labeled IPSec. Another major drawback to the currently available trusted databases is that they have hard-coded policy rules rather than flexible ones. While these hard-coded rules may be appropriate in some scenarios, they often end up being impractical. For instance, any sort of pipeline (like that of my example 3) is difficult if not impossible to implement on most of these hard-coded systems. Additionally, changing the label in most of these systems requires a privilege that lets you bypass the policy rules, while a flexible Type Enforcement system (like SE-PostgreSQL) allows you to specify exactly how relabels should be allowed within the policy. I'll be happy to provide more details where required. Hopefully that provided a little light. Thanks, Chad Sellers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
Re: [HACKERS] 8.4 release planning
On 1/26/09 4:28 PM, Joshua Brindle met...@manicmethod.com wrote: Tom Lane wrote: Josh Berkus j...@agliodbs.com writes: snip SE-Linux: this patch has effectively been in development for 2 years ourside the core process before putting it in; the forked SEPostgres is in use in production. KaiGai has been available for 20 hours a week (or more) to troubleshoot issues and change APIs. I really don't see what the problem is with committing it. The problem, in words of one syllable, is that we are not sure we want it. Do you see a user community clamoring for SEPostgres, or a hacker community that is willing or able to maintain it? If KaiGai-san got run over by a bus tomorrow, this patch would be a dead letter, because there just isn't anyone else who is taking sufficient (any?) interest in it. That doesn't bode well for its future viability. Compare the likely audience for it to previous patches of roughly similar complexity, such as integrated text search or the Windows port, and it's just not in the ballpark. The second problem is that we're not sure it's really the right thing, because we have no one who is competent to review the design from a security standpoint. But unless we get past the first problem the second one is moot. I've never posted to this list before, but I am an SELinux upstream maintainer. I'd just like to interject here, we (the SELinux community) are very interested in KaiGai's work and have been looking forward to it being upstreamed for quite some time. While we haven't been able to analyze the patches directly to determine whether the security goals are indeed being met we have had much discussion and eventually community agreement on the security model being implemented. This happened years ago and has since been merged into the SELinux reference policy that practically all SELinux users use (distributions start with the reference policy and add rules/modules suitable for them). So the security model has been looked at, though not the implementation and we do have a community of developers, users and customers interested in this work. I'd just like to echo Josh's sentiments. I'm also active in the SELinux community, and have been involved in several developments that really needed a database with mandatory access control mechanisms. Unfortunately, these developments have all had maintenance requirements that precluded using KaiGai's code as it was outside not in a commercial distribution. We've been waiting anxiously for it to be merged upstream. Additionally, I've talked to many other end users that really want to deploy LAPP stacks with these security features. They often came to us looking for us to help them build such systems, but we've had to turn them away as there was no supported way to build it. Thanks, Chad Sellers -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers
