Re: refusing connections based on load ...

* Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> [010423 21:54]:
> The Hermit Hacker <scrappy(at)hub(dot)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(at)lerctr(dot)org
US Mail: 1905 Steamboat Springs Drive, Garland, TX 75044-6749