Re: system administration functions with hardcoded superuser checks

There are some system administration functions that have hardcoded
superuser checks, specifically:

pg_reload_conf
pg_rotate_logfile
pg_read_file
pg_read_file_all
pg_read_binary_file
pg_read_binary_file_all
pg_stat_file
pg_ls_dir

Some of these are useful in monitoring or maintenance tools, and the
hardcoded superuser checks require that these tools run with maximum
privileges. Couldn't we just install these functions without default
privileges and allow users to grant privileges as necessary?

On 18 December 2012 17:09, Peter Eisentraut <peter_e(at)gmx(dot)net> wrote:
> There are some system administration functions that have hardcoded
> superuser checks, specifically:
>
> pg_reload_conf
> pg_rotate_logfile
> pg_read_file
> pg_read_file_all
> pg_read_binary_file
> pg_read_binary_file_all
> pg_stat_file
> pg_ls_dir
>
> Some of these are useful in monitoring or maintenance tools, and the
> hardcoded superuser checks require that these tools run with maximum
> privileges. Couldn't we just install these functions without default
> privileges and allow users to grant privileges as necessary?

+1

But I would include recovery functions also.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

2012/12/18 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> There are some system administration functions that have hardcoded
> superuser checks, specifically:
>
> pg_reload_conf
> pg_rotate_logfile
>
> Some of these are useful in monitoring or maintenance tools, and the
> hardcoded superuser checks require that these tools run with maximum
> privileges. Couldn't we just install these functions without default
> privileges and allow users to grant privileges as necessary?

isn't it too strong gun for some people ???

I believe so some one can decrease necessary rights and it opens doors
to system.

> pg_read_file
> pg_read_file_all
> pg_read_binary_file
> pg_read_binary_file_all
> pg_stat_file
> pg_ls_dir

is relative dangerous and I am not for opening these functions.

power user can simply to write extension, but he knows what he does/

Regards

Pavel

>
>
> --
> Sent via pgsql-hackers mailing list (pgsql-hackers(at)postgresql(dot)org)
> To make changes to your subscription:
> http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Dec 18, 2012 at 12:09:10PM -0500, Peter Eisentraut wrote:
> There are some system administration functions that have hardcoded
> superuser checks, specifically:
>
> pg_reload_conf
> pg_rotate_logfile
> pg_read_file
> pg_read_file_all
> pg_read_binary_file
> pg_read_binary_file_all
> pg_stat_file
> pg_ls_dir
>
> Some of these are useful in monitoring or maintenance tools, and the
> hardcoded superuser checks require that these tools run with maximum
> privileges. Couldn't we just install these functions without default
> privileges and allow users to grant privileges as necessary?

+1. You can already use a SECURITY DEFINER wrapper, so I don't think this
opens any particular floodgate. GRANT is a nicer interface. However, I would
not advertise this as a replacement for wrapper functions until pg_dump can
preserve ACL changes to pg_catalog objects.

On Tue, Dec 18, 2012 at 7:41 PM, Noah Misch <noah(at)leadboat(dot)com> wrote:
> On Tue, Dec 18, 2012 at 12:09:10PM -0500, Peter Eisentraut wrote:
>> There are some system administration functions that have hardcoded
>> superuser checks, specifically:
>>
>> pg_reload_conf
>> pg_rotate_logfile
>> pg_read_file
>> pg_read_file_all
>> pg_read_binary_file
>> pg_read_binary_file_all
>> pg_stat_file
>> pg_ls_dir
>>
>> Some of these are useful in monitoring or maintenance tools, and the
>> hardcoded superuser checks require that these tools run with maximum
>> privileges. Couldn't we just install these functions without default
>> privileges and allow users to grant privileges as necessary?
>
> +1. You can already use a SECURITY DEFINER wrapper, so I don't think this
> opens any particular floodgate. GRANT is a nicer interface. However, I would
> not advertise this as a replacement for wrapper functions until pg_dump can
> preserve ACL changes to pg_catalog objects.

Yeah. That is a bit of a foot-gun to this approach, although I too
agree on the general theory.

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

On 18.12.2012 18:38, Pavel Stehule wrote:
> 2012/12/18 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>> There are some system administration functions that have hardcoded
>> superuser checks, specifically:
>>
>> pg_reload_conf
>> pg_rotate_logfile
>>
>> Some of these are useful in monitoring or maintenance tools, and the
>> hardcoded superuser checks require that these tools run with maximum
>> privileges. Couldn't we just install these functions without default
>> privileges and allow users to grant privileges as necessary?
>
> isn't it too strong gun for some people ???
>
> I believe so some one can decrease necessary rights and it opens doors
> to system.

No one was speaking about making them executable by a wider group of
users by default (i.e. decreasing necessary rights). Today, when you
need to provide the EXECUTE privilege on those functions, you have three
options

(a) make him a superuser - obviously not a good choice

(b) create a SECURITY DEFINER wrapper **for each function separately**

(c) deny to do that

Being able to do a plain GRANT on the function is merely a simpler way
to do (b). It has advantages (less objects/functions to care about) and
disadvantages (e.g. you can't do additional parameter values checks).

>> pg_read_file
>> pg_read_file_all
>> pg_read_binary_file
>> pg_read_binary_file_all
>> pg_stat_file
>> pg_ls_dir
>
> is relative dangerous and I am not for opening these functions.
>
> power user can simply to write extension, but he knows what he does/

I see only dangers that are already present.

Tomas

On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
> On 18.12.2012 18:38, Pavel Stehule wrote:
>> 2012/12/18 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>>> There are some system administration functions that have hardcoded
>>> superuser checks, specifically:
>>>
>>> pg_reload_conf
>>> pg_rotate_logfile
>>>
>>> Some of these are useful in monitoring or maintenance tools, and the
>>> hardcoded superuser checks require that these tools run with maximum
>>> privileges. Couldn't we just install these functions without default
>>> privileges and allow users to grant privileges as necessary?
>>
>> isn't it too strong gun for some people ???
>>
>> I believe so some one can decrease necessary rights and it opens doors
>> to system.
>
> No one was speaking about making them executable by a wider group of
> users by default (i.e. decreasing necessary rights). Today, when you
> need to provide the EXECUTE privilege on those functions, you have three
> options

Given how limited these functions are in scope, I don't see a problem here.

>>> pg_read_file
>>> pg_read_file_all
>>> pg_read_binary_file
>>> pg_read_binary_file_all
>>> pg_stat_file
>>> pg_ls_dir
>>
>> is relative dangerous and I am not for opening these functions.
>>
>> power user can simply to write extension, but he knows what he does/
>
> I see only dangers that are already present.

Granting executability on pg_read_xyz is pretty darn close to granting
superuser, without explicitly asking for it. Well, you get "read only
superuser". If we want to make that step as easy as just GRANT, we
really need to write some *very* strong warnings in the documentation
so that people realize this. I doubt most people will realize it
unless we do that (and those who don't read the docs, whch is probably
a majority, never will).

If you use SECURITY DEFINER, you can limit the functions to *the
specific files that you want to grant read on*. Which makes it
possible to actually make it secure. E.g. you *don't* have to give
full read to your entire database.

If you're comparing it to a blanket SECURITY DEFINER with no checks,
then yes, it's a simpler way to fire the cannon into your own foot,
yes. But if also gives you a way that makes it more likely that you
don't *realize* that you're about to fire a cannon into your foot.

--
Magnus Hagander
Me: http://www.hagander.net/
Work: http://www.redpill-linpro.com/

On 19 December 2012 06:34, Magnus Hagander <magnus(at)hagander(dot)net> wrote:

> Granting executability on pg_read_xyz is pretty darn close to granting
> superuser, without explicitly asking for it. Well, you get "read only
> superuser". If we want to make that step as easy as just GRANT, we
> really need to write some *very* strong warnings in the documentation
> so that people realize this. I doubt most people will realize it
> unless we do that (and those who don't read the docs, whch is probably
> a majority, never will).

Good point.

Can we do that explicitly with fine grained superuser-ness?

GRANT SUPERUSER ON FUNCTION .... TO foo;

> If you use SECURITY DEFINER, you can limit the functions to *the
> specific files that you want to grant read on*. Which makes it
> possible to actually make it secure. E.g. you *don't* have to give
> full read to your entire database.

Even better point

> If you're comparing it to a blanket SECURITY DEFINER with no checks,
> then yes, it's a simpler way to fire the cannon into your own foot,
> yes. But if also gives you a way that makes it more likely that you
> don't *realize* that you're about to fire a cannon into your foot.

--
Simon Riggs http://www.2ndQuadrant.com/
PostgreSQL Development, 24x7 Support, Training & Services

On 19.12.2012 07:34, Magnus Hagander wrote:
> On Wed, Dec 19, 2012 at 1:58 AM, Tomas Vondra <tv(at)fuzzy(dot)cz> wrote:
>> On 18.12.2012 18:38, Pavel Stehule wrote:
>>> 2012/12/18 Peter Eisentraut <peter_e(at)gmx(dot)net>:
>>>> There are some system administration functions that have hardcoded
>>>> superuser checks, specifically:
>>>>
>>>> pg_reload_conf
>>>> pg_rotate_logfile
>>>>
>>>> Some of these are useful in monitoring or maintenance tools, and the
>>>> hardcoded superuser checks require that these tools run with maximum
>>>> privileges. Couldn't we just install these functions without default
>>>> privileges and allow users to grant privileges as necessary?
>>>
>>> isn't it too strong gun for some people ???
>>>
>>> I believe so some one can decrease necessary rights and it opens doors
>>> to system.
>>
>> No one was speaking about making them executable by a wider group of
>> users by default (i.e. decreasing necessary rights). Today, when you
>> need to provide the EXECUTE privilege on those functions, you have three
>> options
>
> Given how limited these functions are in scope, I don't see a problem here.
>
>>>> pg_read_file
>>>> pg_read_file_all
>>>> pg_read_binary_file
>>>> pg_read_binary_file_all
>>>> pg_stat_file
>>>> pg_ls_dir
>>>
>>> is relative dangerous and I am not for opening these functions.
>>>
>>> power user can simply to write extension, but he knows what he does/
>>
>> I see only dangers that are already present.
>
> Granting executability on pg_read_xyz is pretty darn close to granting
> superuser, without explicitly asking for it. Well, you get "read only
> superuser". If we want to make that step as easy as just GRANT, we
> really need to write some *very* strong warnings in the documentation
> so that people realize this. I doubt most people will realize it
> unless we do that (and those who don't read the docs, whch is probably
> a majority, never will).

Yup, that's what I meant by possibility to perform "additional parameter
values checks" ;-)

Tomas

Tomas Vondra <tv(at)fuzzy(dot)cz> writes:
> On 19.12.2012 07:34, Magnus Hagander wrote:
>> Granting executability on pg_read_xyz is pretty darn close to granting
>> superuser, without explicitly asking for it. Well, you get "read only
>> superuser". If we want to make that step as easy as just GRANT, we
>> really need to write some *very* strong warnings in the documentation
>> so that people realize this. I doubt most people will realize it
>> unless we do that (and those who don't read the docs, whch is probably
>> a majority, never will).

> Yup, that's what I meant by possibility to perform "additional parameter
> values checks" ;-)

Yeah, which is easily done if you've written a wrapper function and not
so easily otherwise. Between that and the point about how pg_dump
wouldn't preserve GRANTs done directly on system functions, I think this
proposal isn't going anywhere anytime soon.

regards, tom lane

On 12/18/12 12:09 PM, Peter Eisentraut wrote:
> There are some system administration functions that have hardcoded
> superuser checks, specifically:
>
> pg_reload_conf
> pg_rotate_logfile
> pg_read_file
> pg_read_file_all
> pg_read_binary_file
> pg_read_binary_file_all
> pg_stat_file
> pg_ls_dir
>
> Some of these are useful in monitoring or maintenance tools, and the
> hardcoded superuser checks require that these tools run with maximum
> privileges. Couldn't we just install these functions without default
> privileges and allow users to grant privileges as necessary?

This is still being debated, but just for the heck of it, here is a
patch for how this implementation would look like.

2013/1/15 Peter Eisentraut <peter_e(at)gmx(dot)net>:
> On 12/18/12 12:09 PM, Peter Eisentraut wrote:
>> There are some system administration functions that have hardcoded
>> superuser checks, specifically:
>>
>> pg_reload_conf
>> pg_rotate_logfile
>> pg_read_file
>> pg_read_file_all
>> pg_read_binary_file
>> pg_read_binary_file_all
>> pg_stat_file
>> pg_ls_dir
>>
>> Some of these are useful in monitoring or maintenance tools, and the
>> hardcoded superuser checks require that these tools run with maximum
>> privileges. Couldn't we just install these functions without default
>> privileges and allow users to grant privileges as necessary?
>
> This is still being debated, but just for the heck of it, here is a
> patch for how this implementation would look like.
>
Even though it gives flexibility of system configuration, it seems to me too
less-grained access control because above function accept arbitrary
path name, thus, privilege to execution of these function also allows to
reference arbitrary access.

Here are two type of access controls. One is subject-verb-object type;
that describes subject's permitted actions on a particular object.
GRANT/REVOKE command specifies which objects are scope of this
privilege. SELinux is also SVO type.
On the other hand, second is subject-verb type. Superuser privilege
is applied independent from the object. I never heard a root user who
cannot perform as superuser on /etc directory, for example.
I think, it is a reasonable design that above functions right now requires
superuser privilege because it can take arbitrary pathname.

My preference is, above functions (and others that takes pathname
arguments) check SVO style permissions, instead of hardcoded
superuser privilege.
For example, is it a senseless idea to have a mapping table between
database user and operating system user, then call access(2) to
check whether mapped os user have privilege to access this file?

Thanks,
--
KaiGai Kohei <kaigai(at)kaigai(dot)gr(dot)jp>