file_fdw target file ownership

Hi,

When a superuser creates a foreign table with file_fdw, the target file
can belong to any user, as long as postgres can read it.
This is useful when the data files are handed by non-postgres tools,
such as a spreadsheet.
In such a case, it makes sense that the superuser would additionally grant
SELECT on the foreign table to a non-superuser to process the contents.

But once the foreign table is set up, a malicious user owning the file
or even the containing directory can replace it by a link to any file that
can be read only by postgres, such as the server's private key.
With SELECT permission granted on the table, the non-superuser can
then proceed to read the contents in SQL. I've tried it successfully
with 9.3rc1.

As a result, it means that an admin should not allow a file as the target of
a foreign table if it can be replaced on the filesystem by a non-postgres
user. It may be writable by a non-postgres user, though, which is
quite useful with moving data.

This is a bit subtle. To avoid the whole issue, how about adding an
option in file_fdw forcing it to check each time it opens the file
that its ownership and maybe permissions have not changed
since CREATE FOREIGN TABLE?

Or is there a simpler way to deal with the above case?

Best regards,
--
Daniel Vérité
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org

On 2013-09-08 20:00:58 +0200, Daniel Vérité wrote:
> Or is there a simpler way to deal with the above case?

One would be to use open(O_NOFOLLOW)?

But more generally I am of the opinion that it's the superusers
responsibility to make sure that cannot happen by only using properly
secured files.

Greetings,

Andres Freund

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

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-09-08 20:00:58 +0200, Daniel Vrit wrote:
>> Or is there a simpler way to deal with the above case?

> One would be to use open(O_NOFOLLOW)?

That would only stop symlink attacks, not hardlink variants;
and it'd probably stop some legitimate use-cases too.

> But more generally I am of the opinion that it's the superusers
> responsibility to make sure that cannot happen by only using properly
> secured files.

Yeah. ISTM that any restriction we could add that would prevent this
would present a serious obstacle to many legitimate use-cases as well.

It might be reasonable to document the scenario Daniel describes,
though.

regards, tom lane

Tom Lane writes:

> Andres Freund <andres(at)2ndquadrant(dot)com> writes:

> > One would be to use open(O_NOFOLLOW)?
>
> That would only stop symlink attacks, not hardlink variants;
> and it'd probably stop some legitimate use-cases too.

The creation of the hardlink is denied by the OS based on the
attacker not having sufficient permissions to the target file.
In principle the mentioned loophole is limited to a symlink, which
is not restricted at create time.

Thinking a bit more about the scenario of the malicious writer,
I think the secure way to proceed for the superuser would be to
set up two directories, one with write permissions to the
producer of data, the other without.

The superuser would have to move the file from the writable
dir to the non-writable dir, before creating the foreign table. The
file itself should remain writable by the uploader if it's live data.
The data-producer has to be aware that updates happen
at a different path than uploads.

The problem is that it's really not intuitive. I can imagine unaware
admins implementing the insecure process without a second thought.

By contrast, if symlinks were followed only optionally, it would
be safer as a default choice and the installations that need symlinks could
still use something like:

CREATE FOREIGN TABLE (...) SERVER name
OPTIONS (symlink_allowed 'on', filename '/path/to/file', ...)

The mere existence of the option is a hint that there are consequences
to consider.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org

On 2013-09-09 21:41:00 +0200, Daniel Vérité wrote:
> Tom Lane writes:
>
> > Andres Freund <andres(at)2ndquadrant(dot)com> writes:
>
> > > One would be to use open(O_NOFOLLOW)?
> >
> > That would only stop symlink attacks, not hardlink variants;
> > and it'd probably stop some legitimate use-cases too.
>
> The creation of the hardlink is denied by the OS based on the
> attacker not having sufficient permissions to the target file.
> In principle the mentioned loophole is limited to a symlink, which
> is not restricted at create time.

It only requires search privileges, doesn't it?

andres(at)alap2:~$ ln /etc/shadow /tmp/frak
andres(at)alap2:~$ cat /tmp/frak
cat: /tmp/frak: Permission denied
andres(at)alap2:~$ ls -l /tmp/frak
-rw-r----- 2 root shadow 1652 Jun 4 22:05 /tmp/frak

There are patches around preventing that kind of thing, but they aren't
too widespread yet.

Greetings,

Andres Freund

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

Andres Freund <andres(at)2ndquadrant(dot)com> writes:
> On 2013-09-09 21:41:00 +0200, Daniel Vrit wrote:
>> Tom Lane writes:
>>> That would only stop symlink attacks, not hardlink variants;

>> The creation of the hardlink is denied by the OS based on the
>> attacker not having sufficient permissions to the target file.

> It only requires search privileges, doesn't it?

Yeah, it would be a mistake to assume that the OS will prevent a hardlink
operation based on file ownership. Even if some OSes behave that way,
it's far from universal.

It's true that an attacker has to be able to name the target file to do a
hardlink, so if he lacks search privileges on a parent directory then he
can't hardlink (but he can still mount a symlink attack, if he knows what
the path name would be). So preventing the symlink variant would help for
the particular case of a PG server key stored inside $PGDATA. But it
doesn't seem to me that that's enough coverage to call it a solution.
People sometimes keep server keys elsewhere, for instance.

regards, tom lane

Andres Freund writes

> andres(at)alap2:~$ ls -l /tmp/frak
> -rw-r----- 2 root shadow 1652 Jun 4 22:05 /tmp/frak

Ah, indeed.
It fails for me though (Ubuntu 12.04, linux 3.2.0, ext4):

$ ln /etc/shadow /tmp/frak
ln: failed to create hard link `/tmp/frak' => `/etc/shadow': Operation not
permitted

but I can see it succeed on older linux.

Still $PGDATA with its rwx------ permissions is insulated from
any such hard-linking from outsiders, whereas a soft link can point
anywhere.

Best regards,
--
Daniel Vérité
PostgreSQL-powered mail user agent and storage: http://www.manitou-mail.org