On Wed, Mar 21, 2012 at 6:07 AM, Kohei KaiGai <kai...@kaigai.gr.jp> wrote: > The reason why dynamic domain transition should be configured > carefully is that it partially allows users to switch their own privileges > in discretionary way, unlike trusted procedure. > > The original model of selinux on operating system assumes all the > domain transition shall happen on execve(2) time, but it made clear > some sort of application is not happy with traditional fork - exec > lifecycle, such as web server, connection pooling software, or others. > > Even as they perform according to the operations from users, > it does not fork - exec itself because of some reason, typically > performance. One point we should focus on is these applications > have relatively trustable portion and untrustable one. > > The dynamic domain transition was designed to "restrict" privileges > more than the current one on the trustable portion, prior to launch > untrustable one. So, it never intend to switch client domain with > 100% arbitrary. Its bottom line is restricted with the security policy; > that explicitly describes the range of domains being allowed to > translate. > > So, we will be able to conclude dynamic domain transition is > harmless as long as it works to reduce privileges; that should > be guaranteed with the security policy. > It also means sepgsql_setcon() is harmless as long as it works > according to the decision of SELinux. > > The connection pooling software scenario using trusted procedure > might be a bit confusing. In this case, the client domain is once > switched to the trusted one with mandatory way, then it switches > to more restricted domain in arbitrary way; thus, it is not allowed > to promote its privileges in arbitrary way. > We assume the trusted procedure is a enough small portion to > ensure bug or vulnerability free. > > Joshua, please add some comments, if you have.
I guess my feeling on this is that the warning in the documentation isn't really helping anything here. I mean, we don't need to document that allowing people to give themselves more privileges is a security hole; that much is obvious. -- Robert Haas EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers