Fwd: init scripts and su

Peter Eisentraut <peter_e@gmx.net> writes:

For your amusement...

During the time between the daemon launch and it closing it's file
handles and calling setsid(2) (which some daemons don't do because
they are buggy) any other code running in the same UID could take over
the process via ptrace, fork off a child process that inherits the
administrator tty, and then stuff characters into the keyboard buffer
with ioctl(fd,TIOCSTI,&c) (*).

(a) And there would be untrusted code running as postgres exactly why?

(b) Seems to me the real security bug here is the mere existence of that
ioctl call.

regards, tom lane

During the time between the daemon launch and it closing it's file
handles and calling setsid(2) (which some daemons don't do because
they are buggy) any other code running in the same UID could take over
the process via ptrace, fork off a child process that inherits the
administrator tty, and then stuff characters into the keyboard buffer
with ioctl(fd,TIOCSTI,&c) (*).

(a) And there would be untrusted code running as postgres exactly why?

(b) Seems to me the real security bug here is the mere existence of that
ioctl call.

I was asked on IRC just why we can't have user=postgres and
group=postgres in the postgresql.conf, and simply when we are run as
root, switch to that user and group.

Chris

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

I was asked on IRC just why we can't have user=postgres and
group=postgres in the postgresql.conf, and simply when we are run as
root, switch to that user and group.

I should think that running as root up until sometime after we have read
postgresql.conf would open up more security issues. It's certainly not
a way to close this one...

regards, tom lane

Tom Lane wrote:

Christopher Kings-Lynne <chriskl@familyhealth.com.au> writes:

I was asked on IRC just why we can't have user=postgres and
group=postgres in the postgresql.conf, and simply when we are run as
root, switch to that user and group.

I should think that running as root up until sometime after we have read
postgresql.conf would open up more security issues. It's certainly not
a way to close this one...

postmaster could use postgres/postgres by default, overridable by
command line.

Regards,
Andreas

Tom Lane wrote:

(a) And there would be untrusted code running as postgres exactly
why?

Because someone has cracked the PostgreSQL server.

(b) Seems to me the real security bug here is the mere existence of
that ioctl call.

Probably. I'm just pointing out the findings about the environment
we're operating in. The fact is that right now "run as postgres to
protect your root account" won't work on some systems and with
unfortunately written init scripts.

--
Peter Eisentraut
http://developer.postgresql.org/~petere/