Re: refusing connections based on load ...

* Tom Lane <tgl@sss.pgh.pa.us> [010423 21:54]:
> The Hermit Hacker <scrappy@hub.org> writes:

> 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 my UnixWare box it's 0440 sys.sys....

> 
> 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.
Then there are boxes like my UnixWare one where the load average is
not available AT ALL:

$ uptime 10:05pm  up 2 days,  3:16,  3 users
$ 

It's a threaded kernel, and SCO/Novell/whoever has removed all traces
from userland of the load average.  avenrun[] is still a symbol in the
kernel, but...


-- 
Larry Rosenman                     http://www.lerctr.org/~ler
Phone: +1 972-414-9812                 E-Mail: ler@lerctr.org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749