What sence does it make to run services < port 1024 chrooted? All those need root rights ... and you can break out of a chrooted environment ... some services like BIND drop the root privilege once they initialised afaik ... but other's don't.

Isn't that itself a risk ?
Workarounds ?

What sense does it make to run services < port 1024 chrooted? All those need root rights ... and you can break out of a chrooted environment
A daemon can drop root privs after binding to a port. That doesn't have anything to do with jailing but how the daemon handles dropping privileges.A chroot acts as a prevention mechanism against further corruption, so that once the cracker has gained access she will only find a rather sparse fs layout :-]
Breaking out of a chroot can be done using /dev/kmem (Silvio Cesare's papers), chroot-in-a-chroot (bpfh.net), exploiting a setuid root app, following slinks out of the jail and a few more.
(By now I'm getting the faint idea I'm recycling some older post?)

some services like BIND drop the root privilege once they initialised afaik ... but other's don't. Isn't that itself a risk ?
Yes. If only it's effective uid (using seteuid) is changed chances are it may regain root privs. Please reread my post on Grsecurity or check the patch/docs out, Trusted Path Execution, PAX (stack protection), extensive chroot enforcements and auditing, read-only /dev/kmem, /proc restrictions and the stuff you add yourself like setuid binary auditing, chattering stuff, removing unnecessary passwds etc etc should make a chroot nearly unbreakable.

Workarounds ?
Except for the above?, depends on what it is. For some: run a daemon bound to 127.0.0.1:someport and let one on the other side of the fence interact with it, redirect the port (say 21) up into the ephemeral range to say 8021 and run the daemon there. For others: su -m some_user -c '<cmd> <args>' or if you don't trust it, don't run it :-]

I like to run Flawfinder/Rats before I compile. If I pick up interesting, I'll read the code. I'm not that good, so first thing I usually start is checking for seteuid instead of setuid :-]
When I'm lazy I'll just go for inserting a quick
if (getuid() == 0) {
printf("We run as root.\n");
to see where it end up at.

// I apologize in advance as this isn't all that elaborate as I like it to be but I've gotta finish some docs. Everyone hates the evil D word :-]

In case of apache v2.0.43:

root 16155 0.1 0.3 4536 2028 ? S 10:10 0:00 /server/http/binary/bin/httpd -k start
nobody 14996 0.0 0.3 4472 1964 ? S 10:10 0:00 /server/http/binary/bin/httpd -k start
nobody 18469 0.0 0.3 4560 2048 ? S 10:10 0:00 /server/http/binary/bin/httpd -k start
nobody 16327 0.0 0.3 4560 2048 ? S 10:10 0:00 /server/http/binary/bin/httpd -k start
nobody 12332 0.1 0.3 4560 2048 ? S 10:10 0:00 /server/http/binary/bin/httpd -k start
nobody 26122 0.0 0.3 4560 2048 ? S 10:10 0:00 /server/http/binary/bin/httpd -k start
nobody 19183 0.0 0.3 4560 2048 ? S 10:10 0:00 /server/http/binary/bin/httpd -k start

So there is still a process left running as root ...

Apache's main process runs as root to be able to bind to the privved port. Theoretically speaking you would need to trick the main Apache process into doing Something Evil. It's children, don't run as root. They're the ones handling user requests, so you can't interface with that process from the 'net (AFAIK).

But why doesn't the main process drop the root privilege then like BIND does? It doesn't need root privileges any more ...

Ok. One way to "audit" a process would be to look at it's capabilities. Since kernel-2.2x they're incorporated in the kernel, see the Linux capabilities FAQ.

Touching on security the Linux kernel handles a "global" capabilities list in /proc/sys/kernel/capbound: bounding capabilities. These global caps can be taken away using "lcap". They are not permanent, but can not be changed or restored unless you shutdown -r or give the box the three-finger salute (ALT+SYSRQ+B), so be carefull.

Now a process can have caps too. Caps determine what an app has access to, like CAP_SYS_RAWIO or the ability to write to /dev/kmem. Note this is one of the worst kinds of access and serves as one of the vectors Silvio Cesare describes to break out of a chroot.

A cap of interest in case of Apache would be CAP_NET_BIND_SERVICE or the ability to bind to ports below 1024.
With the extremely lazy and simple script [removed] (and it's dependency in place) you can have a quick glance at what effective caps a process has.

Here's example output of running Apache-SSL:
"man lcap" sez :
0 CAP CHOWN
Override restrictions on changing file ownership.
In a system with the [_POSIX_CHOWN_RESTRICTED]
option defined, this overrides the restriction of
changing file ownership and group ownership.

10 CAP NET BIND SERVICE
Allow binding to sockets below 1024. Allows bind_
ing to TCP/UDP sockets below 1024. Allows binding
to ATM VCIs below 32.

19 CAP SYS PTRACE
Allow tracing of any process.

Since we're looking at effectivecapabilities, this means that after dropping all other capabilities these remain, kewl by me.

// Work In Progress, or "this leaves two questions open":
I. why does the main process (still) has those caps? (Your original question) and (parent->child, need to explain from code, rhhaaahhh),
II. can it regain capabilities? (I need to shove some example in like SUID mtr seteuid stylee).
I'll try 'n find an answer to these the coming week. Should make for a good excercise :-]

Where to get lcap ?
I tried a google and freshmeat search and didn't come across a still existing website ...

SF have got a copy of the tarball, else try for the RPM.

But why doesn't the main process drop the root privilege then like BIND does? It doesn't need root privileges any more ...

I guess that since it binds the socket to the interface that if it drops the privileges it can't have rights to using the socket? Running a strace on Apache-SSL shows the parent process listening to :80 and then just idling as uid=0, any "worker" processes with uid!=0 seeks for an established connection > 1024 and read/write there until killed by parent.

"Apache (on Unix) is a pre-forking model server. The parent process is responsible only for forking child processes, it does not serve any requests or service any network sockets. The child processes actually process connections, they serve multiple connections (one at a time) before dying. The parent spawns new or kills off old children in response to changes in the load on the server (it does so by monitoring a scoreboard which the children keep up to date)."
(http://httpd.apache.org/docs/misc/perf-tuning.html)

I don't know how BIND operates this way: next to UDP/53 it still needs send/receivs on TCP/53 (redundancy|zone xfers).

Thanks a lot for your analysis work :-)

Np, still got the full traces if you want to go over it.

Maybe another time :-)