Greg Stark wrote: > So I'm unclear what advantage this has for Redhat and sysadmins over > just setting up the database directly but then I'm unclear what the > advantage is for SELinux in the first place so I'm probably just not > in the target audience for it. But this seems like it would be > directly analogous. I suppose an admin would be able to delegate more > control to a new admin
We (security engineers) consider to coordinate access controls on whole of the system, not only database, although it might be an irritating wordage for pgsql-hackers. Needless to say, database is one of the most significant software components nowadays, but not all. From the perspective of security administration, we want to restrict user's privileges using a centralized basis, called security policy. The basis needs to be independent from structures of a certain subsystem, such as OS or DBMS. SELinux is well suitable for the requirements in Linux. Note that SELinux is implemented as a feature of OS in fact, but it makes its access control decision based on only a couple of security contexts which is a class-independent identifier. (It is called "reference monitor" in security region.) It is not a good idea to invent an another framework again for whole of the system security, because many of userspace applications already support SELinux features. It also means stuff to manage security context of resources, not only applying additional access controls based on SELinux policy like SE-PgSQL. For example, "ls -Z" shows security context of files, "mv" keeps security context of files, even if user tries to move a file across filesystems, "tar --selinux" support backup/restore security context of the files, ... There are various kind of options, however, SELinux provides most widespread support on various kind of software components. If we would be Oracle, we may be able to provide whole of the software components. But it is not right way in OSS community. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kai...@ak.jp.nec.com> -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers