From: KaiGai Kohei <kaigai@ak.jp.nec.com> To: Stephen Smalley <sds@tycho.nsa.gov> Cc: selinux <selinux@tycho.nsa.gov>, refpolicy@oss.tresys.com Subject: Re: The status of SE-PostgreSQL Date: Tue, 24 Mar 2009 10:13:50 +0900 [thread overview] Message-ID: <49C833CE.4000206@ak.jp.nec.com> (raw) In-Reply-To: <1237821939.8667.27.camel@localhost.localdomain> >> See the following items, >> >> * new permission: db_database:{superuser} >> >> They required a new permission to control database superuser >> privileges similar to "root" capability in operating system. >> The concept of superuser is common for some of major DBMSs, >> not only PostgreSQL. In addition, it seems to me well symmetric >> with operating system. >> >> The db_database:{superuser} controls whether the client can >> perform as database superuser on the given database, or not. > > Any chance of splitting this up into finer-grained privileges? I basically think it is good idea from the viewpoint of security. However, if they separate the superuser privige into finer-grained ones without SQL specification, its design will fully depends on PostgreSQL. > And what precisely are the implications of this permission: does it > effectively make all of the other permission checks irrelevant for the > subject? In comparison, the SELinux capability permissions only allow > the subject to override e.g. DAC file checks, not the SELinux MAC file > checks. In currently, it checks the context of client (subject) and the one of database (object), but it can be fixed soon. We already have several permissions on db_database class. Some of them are checked on the database object, and the "superuser" is checked on the subject itself. Is it no matter? >> * undesired permission: db_database:{set_param get_param} >> >> They wondered the necessity of these checks, because SQL spec >> does not require checks in set/get database parameters. >> I didn't think it is necessary the security design of SELinux >> should be symmetric with SQL, but I also thought these might >> be unnecessary due to another reason. >> In PostgreSQL, the scope of database parameters are session >> local and initialized on the connection startup, so we cannot >> use it as a pass to communicate between different two or more >> domains. > > Are any of the database parameters security-relevant (not just > information flow)? It provide a parameter of "sepostgresql=(on|off)" to turn on/off its feature, but it is not allowed to change via SQL commands. This parameter is initialized with the configuration file on the server startup time, then it is handled as read-only. If a man who can modify "$PGDATA/postgresql.conf" disables SE-PostgreSQL, we have the matter in different place. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com> -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@tycho.nsa.gov with the words "unsubscribe selinux" without quotes as the message.
WARNING: multiple messages have this Message-ID (diff)
From: kaigai@ak.jp.nec.com (KaiGai Kohei) To: refpolicy@oss.tresys.com Subject: [refpolicy] The status of SE-PostgreSQL Date: Tue, 24 Mar 2009 10:13:50 +0900 [thread overview] Message-ID: <49C833CE.4000206@ak.jp.nec.com> (raw) In-Reply-To: <1237821939.8667.27.camel@localhost.localdomain> >> See the following items, >> >> * new permission: db_database:{superuser} >> >> They required a new permission to control database superuser >> privileges similar to "root" capability in operating system. >> The concept of superuser is common for some of major DBMSs, >> not only PostgreSQL. In addition, it seems to me well symmetric >> with operating system. >> >> The db_database:{superuser} controls whether the client can >> perform as database superuser on the given database, or not. > > Any chance of splitting this up into finer-grained privileges? I basically think it is good idea from the viewpoint of security. However, if they separate the superuser privige into finer-grained ones without SQL specification, its design will fully depends on PostgreSQL. > And what precisely are the implications of this permission: does it > effectively make all of the other permission checks irrelevant for the > subject? In comparison, the SELinux capability permissions only allow > the subject to override e.g. DAC file checks, not the SELinux MAC file > checks. In currently, it checks the context of client (subject) and the one of database (object), but it can be fixed soon. We already have several permissions on db_database class. Some of them are checked on the database object, and the "superuser" is checked on the subject itself. Is it no matter? >> * undesired permission: db_database:{set_param get_param} >> >> They wondered the necessity of these checks, because SQL spec >> does not require checks in set/get database parameters. >> I didn't think it is necessary the security design of SELinux >> should be symmetric with SQL, but I also thought these might >> be unnecessary due to another reason. >> In PostgreSQL, the scope of database parameters are session >> local and initialized on the connection startup, so we cannot >> use it as a pass to communicate between different two or more >> domains. > > Are any of the database parameters security-relevant (not just > information flow)? It provide a parameter of "sepostgresql=(on|off)" to turn on/off its feature, but it is not allowed to change via SQL commands. This parameter is initialized with the configuration file on the server startup time, then it is handled as read-only. If a man who can modify "$PGDATA/postgresql.conf" disables SE-PostgreSQL, we have the matter in different place. Thanks, -- OSS Platform Development Division, NEC KaiGai Kohei <kaigai@ak.jp.nec.com>
next prev parent reply other threads:[~2009-03-24 1:13 UTC|newest] Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top 2009-03-23 10:37 The status of SE-PostgreSQL KaiGai Kohei 2009-03-23 10:37 ` [refpolicy] " KaiGai Kohei 2009-03-23 14:56 ` Shaz 2009-03-23 14:57 ` Shaz 2009-03-23 15:19 ` Andy Warner 2009-03-24 2:14 ` KaiGai Kohei 2009-03-24 2:14 ` [refpolicy] " KaiGai Kohei 2009-03-25 6:54 ` Some ideas in SE-PostgreSQL enhancement (Re: The status of SE-PostgreSQL) KaiGai Kohei 2009-03-25 6:54 ` [refpolicy] " KaiGai Kohei 2009-03-25 7:45 ` Andy Warner 2009-03-25 8:20 ` KaiGai Kohei 2009-03-25 8:59 ` Andy Warner 2009-03-25 12:00 ` KaiGai Kohei 2009-03-25 17:02 ` Andy Warner 2009-03-26 0:13 ` KaiGai Kohei 2009-03-25 17:43 ` Joshua Brindle 2009-03-25 19:42 ` Andy Warner 2009-03-27 15:43 ` Joshua Brindle 2009-03-27 16:25 ` Andy Warner 2009-03-27 17:15 ` Joshua Brindle 2009-03-27 17:54 ` Andy Warner 2009-03-27 18:12 ` Joshua Brindle 2009-03-27 18:48 ` Andy Warner 2009-03-27 19:53 ` Joshua Brindle 2009-03-27 20:04 ` Andy Warner 2009-03-27 23:59 ` KaiGai Kohei 2009-03-28 7:17 ` Andy Warner 2009-03-30 0:56 ` KaiGai Kohei 2009-03-30 8:21 ` KaiGai Kohei 2009-03-30 9:58 ` Andy Warner 2009-03-30 13:22 ` KaiGai Kohei 2009-04-22 0:08 ` Eamon Walsh 2009-04-22 3:59 ` KaiGai Kohei 2009-05-01 4:54 ` Eamon Walsh 2009-05-07 1:34 ` KaiGai Kohei 2009-05-07 7:24 ` KaiGai Kohei 2009-03-30 9:49 ` Andy Warner 2009-03-26 5:50 ` [PATCH] Expose avc_netlink_loop() for applications (Re: Some ideas in SE-PostgreSQL enhancement) KaiGai Kohei 2009-03-26 23:28 ` Eamon Walsh 2009-03-26 23:41 ` Eamon Walsh 2009-03-27 0:35 ` KaiGai Kohei 2009-03-28 0:54 ` Eamon Walsh 2009-03-28 2:00 ` KaiGai Kohei 2009-03-30 4:56 ` KaiGai Kohei 2009-03-26 6:11 ` [PATCH] database audit integration " KaiGai Kohei 2009-03-26 6:11 ` KaiGai Kohei 2009-03-26 21:45 ` John Dennis [not found] ` <49CB313B.7020507@redhat.com> 2009-03-27 2:34 ` KaiGai Kohei 2009-03-27 2:34 ` KaiGai Kohei 2009-03-26 8:29 ` [PATCH] Permissive domain in userspace " KaiGai Kohei 2009-03-28 2:41 ` Eamon Walsh 2009-03-30 2:55 ` KaiGai Kohei 2009-03-31 1:45 ` KaiGai Kohei 2009-03-31 16:46 ` Stephen Smalley 2009-04-01 1:07 ` [PATCH] Permissive domain in userspace object manager KaiGai Kohei 2009-04-01 1:41 ` KaiGai Kohei 2009-04-01 12:34 ` Stephen Smalley 2009-04-01 20:07 ` Eric Paris 2009-04-01 22:53 ` James Morris 2009-03-27 8:18 ` [PATCH] Policy rework for SE-PostgreSQL (Re: Some ideas in SE-PostgreSQL enhancement) KaiGai Kohei 2009-03-27 8:18 ` [refpolicy] " KaiGai Kohei 2009-03-27 9:44 ` Andy Warner 2009-03-27 11:20 ` KaiGai Kohei 2009-03-27 11:20 ` [refpolicy] " KaiGai Kohei 2009-03-27 11:45 ` Andy Warner 2009-03-27 11:45 ` [refpolicy] " Andy Warner 2009-03-27 12:17 ` KaiGai Kohei 2009-03-27 12:17 ` [refpolicy] " KaiGai Kohei 2009-04-01 7:26 ` Correct manner to handler undefined classes/permissions? " KaiGai Kohei 2009-04-01 12:45 ` Stephen Smalley 2009-04-02 0:28 ` KaiGai Kohei 2009-03-23 15:25 ` The status of SE-PostgreSQL Stephen Smalley 2009-03-23 15:25 ` [refpolicy] " Stephen Smalley 2009-03-24 1:13 ` KaiGai Kohei [this message] 2009-03-24 1:13 ` KaiGai Kohei
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=49C833CE.4000206@ak.jp.nec.com \ --to=kaigai@ak.jp.nec.com \ --cc=refpolicy@oss.tresys.com \ --cc=sds@tycho.nsa.gov \ --cc=selinux@tycho.nsa.gov \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.