Re: allowing privileges on untrusted languages

On Fri, Jan 25, 2013 at 2:59 PM, Kohei KaiGai <kaigai@kaigai.gr.jp> wrote:
> 2013/1/20 Tom Lane <tgl@sss.pgh.pa.us>:
>> Robert Haas <robertmhaas@gmail.com> writes:
>>> Yeah.  We'd need to think a little bit about how to make this work,
>>> since I think that adding a gajillion booleans to pg_authid will not
>>> make anyone very happy.  But I like the idea.  GRANT
>>> kill_sessions_of_other_users TO bob?  GRANT install_untrusted_pls TO
>>> any_database_owner?  GRANT install_an_extension_called(hstore) TO
>>> any_database_owner?  I know there are other ways of doing all of these
>>> things, so don't take the specific proposals too seriously, but we
>>> clearly have a need to parcel out controlled bits of the superuser
>>> mojo to individual users in a nice, clean, convenient way.  Getting
>>> agreement on the details is likely to be difficult, but it seems like
>>> a good concept from 10,000 feet.
>>
>> The traditional answer to that, which not only can be done already in
>> all existing releases but is infinitely more flexible than any
>> hard-wired scheme we could implement, is that you create superuser-owned
>> security-definer functions that can execute any specific operation you
>> want to allow, and then GRANT EXECUTE on those functions to just the
>> people who should have it.
>>
> I also agree it is a right solution to provide unprivileged users a trusted
> way to handle privileged operations, as set-uid programs are widely
> utilized for same purpose on operating system, however, it needs to
> satisfy an assumption these trusted procedures have to be free from
> bugs and vulnerabilities. In general, it is not an easy assumption.
> Thus, it is the reason why fine-grained capability is preferred than
> root as single-point-of-failure on security. For example, now /bin/ping
> has no set-uid bit on recent Fedora system, to avoid a risk when this
> program has any vulnerability.
>
>   [kaigai@iwashi ~]$ ls -l /bin/ping
>   -rwxr-xr-x. 1 root root 40880 Dec  7 15:19 /bin/ping
>   [kaigai@iwashi ~]$ getcap /bin/ping
>   /bin/ping = cap_net_admin,cap_net_raw+ep
>
> I think, our situation is similar. If DBA is not 100% certain on safeness
> of self-defined functions, I believe he want unprivileged users to call
> security-definer functions owned by limited capable user, instead of
> fully capable superuser.
>
> I'm not positive to over-interpret this concept, like hundred of capabilities
> being nightmare of maintenance. However, it is worthwhile as basis
> of self-defined security-definer functions.
> I'd like people to imagine a case when trusted procedures were buggy.

This is valid, but I think that the people who want this functionality
are less interest in avoiding bugs in trusted procedures than they are
in avoiding the necessity for the user to have to learn the local
admin-installed collection of trusted procedures.  In other words, the
value in being able to run CREATE EXTENSION on_the_whitelist rather
than SELECT my_secdef_create_extension('on_the_whitelist') is that the
user is presumed to be already familiar with the former.  I can see
the logic in that, though it does pose some implementation challenges.

-- 
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company