On Thu, 2005-01-13 at 06:41, Dawid Kuroczko wrote:
> On Thu, 13 Jan 2005 12:20:41 +0000, Dick Davies
> <rasputnik@hellooperator.net> wrote:
> > > But only if either setuid root or executed by root. Hey, on my
> > > system even /bin/sh is owned by root; it would be funny of it
> > > executed as root
> > C'mon folks, the guy obviously made a booboo - no need to rub his
> > nose in it...
>
> I apologize if it felt like it. Anyway, I've been thinking about it a bit;
> if pgsql files are owned by pgsql and some BAD user with too high
> privileges (say, plperlU or other unrestricted access), she can modify
> database files (like remove everything from data directory, etc.), and
> it matters little if files are owned by root or postgres -- the database
> data is owned by postgres.
>
> However, if she is really BAD, she can prepare her own version of say,
> psql binary (which will "invisibly" grant her access to all victims tables
> for instance) and overwrite PostgreSQL's original version with her own.
>
> If the files are owned by root, she cannot do it (though she can try
> making postgres suid shell binary in /tmp, etc. etc. etc.). :-)
The real danger here shows up in daemons that are started by root by the
necessity of opening a port <1024, like apache. These processes then
change to another user once running, or for the spawned children.
Imagine that apache was installed under the httpd user, not root.
Since the httpd user would then own the httpd binary, it is possible
that if someone were to get the httpd daemon to write over the
/bin/httpd file, that upon startup, the root user attempting to execute
the httpd daemon could be running someone else's code with roots
privileges.
This isn't a problem for postgresql, since it is started by a non-root
user from the beginning.
I too have had to deal with auditors whose understanding of security,
and unix security in particular, was sub optimal, so I kow what Dick
here is talking about on that account. In fact I had one arguing this
exact same point five or so years ago about our apace installation, and
it took nearly all day to point out the flaw in his logic and get him to
sign off on my installation.
