Re: [HACKERS] Adding support for SE-Linux security
On 12/8/09 12:36 PM, "Robert Haas" wrote: > On Tue, Dec 8, 2009 at 12:16 PM, Chad Sellers wrote: >> On 12/8/09 11:51 AM, "David P. Quigley" 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 >>>> wrote: >>>>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: >>>>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian 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 to
Re: [HACKERS] Adding support for SE-Linux security
On 12/8/09 11:51 AM, "David P. Quigley" 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 >> wrote: >>> On Mon, 2009-12-07 at 17:57 -0500, Robert Haas wrote: >>>> On Mon, Dec 7, 2009 at 1:00 PM, Bruce Momjian 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] How to get SE-PostgreSQL acceptable
On 1/30/09 5:43 PM, "Josh Berkus" 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 6:57 PM, "Greg Smith" 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/27/09 4:40 PM, "Ron Mayer" 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/26/09 4:28 PM, "Joshua Brindle" wrote: > Tom Lane wrote: >> Josh Berkus writes: >>> 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
