Re: refusing connections based on load ...

other then a potential buffer overrun, what would be the problem with:

open(kmem)
read values
close(kmem)

?

I would think it would be less taxing to the system then doing a system()
call, but still effectively as safe, no?

On Mon, 23 Apr 2001, Tom Lane wrote:

> The Hermit Hacker <scrappy@hub.org> writes:
> > On Mon, 23 Apr 2001, Tom Lane wrote:
> >> sendmail expects to be root.
>
> > Actually, not totally accurate ... sendmail has a 'RunAs' option for those
> > that don't wish to have it run as root,
>
> True, it doesn't *have* to be root, but the loadavg code still requires
> privileges beyond those of mere mortals (as does listening on port 25,
> last I checked).
>
> On my HPUX box:
>
> $ ls -l /dev/kmem
> crw-r-----   1 bin        sys          3 0x000001 Jun 10  1996 /dev/kmem
>
> so postgres would have to run setuid bin or setgid sys to read the load
> average.  Either one is equivalent to giving an attacker the keys to the
> kingdom (overwrite a few key /usr/bin/ executables and wait for root to
> run one...)
>
> On Linux and BSD it seems to be more common to put /dev/kmem into a
> specialized group "kmem", so running postgres as setgid kmem is not so
> immediately dangerous.  Still, do you think it's a good idea to let an
> attacker have open-ended rights to read your kernel memory?  It wouldn't
> take too much effort to sniff passwords, for example.
>
> Basically, if we do this then we are abandoning the notion that Postgres
> runs as an unprivileged user.  I think that's a BAD idea, especially in
> an environment that's open enough that you might feel the need to
> load-throttle your users.  By definition you do not trust them, eh?
>
> A less dangerous way of approaching it might be to have an option
> whereby the postmaster invokes 'uptime' via system() every so often
> (maybe once a minute?) and throttles on the basis of the results.
> The reaction time would be poorer, but security would be a whole lot
> better.
>
>             regards, tom lane
>

Marc G. Fournier                   ICQ#7615664               IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org           secondary: scrappy@{freebsd|postgresql}.org