modifying linux to allow non-root to use port <1024

[CTho9305]

What's required? wouldn't it make sense to run apache as non-root if you're running possibly unsafe scripts (read: scripts written by a clueless fool like me ) instead of root? a buffer overflow in a c program I write would be useless as non-root.

It occured to me that I could just set up a redirect to a webserver on a higher port, but thats not as fun

 

[CTho9305]

bump

 

[Nothinman]

Apache has a User and Group directive for this, it drops root privileges and becomes that user after startup.

 

[manly]

Apache and most other well-written Unix daemons start up with root permissions to bind to privileged ports, but drop to regular user credentials thereafter.

A standard convention is to drop to a user called nobody that belongs to a group called nogroup.

Basically, this user account is sandboxed, and even if Apache is compromised, there's little risk that the machine is rooted.

It's a standard convention that root credentials are needed to bind to privileged ports, so this isn't going to change.

 

[CTho9305]

cool, I didn't know that

 

[Nothinman]

A standard convention is to drop to a user called nobody that belongs to a group called nogroup.

This was a good idea until everyone started using it, then so many services started using nobody:nogroup they became important.

What most distros do now is setup a seperate user:group for each service so they really are sandboxed, RedHat uses apache:apache by default, Debian www-data:www-data, etc.

 

[n0cmonkey]

I dont think Apache does this by default, but setting up a chroot environment might also be a good idea.

 

[Nothinman]

I dont think Apache does this by default, but setting up a chroot environment might also be a good idea.

Yes but then you have to move all the dependencies in there too, like if your scripts use perl, you have to have another perl installation down there. It's easy to chroot things like ftp and bind because they have few external dependencies, doing it to Apache would probably be more trouble than it's worth.

 

[n0cmonkey]

<< I dont think Apache does this by default, but setting up a chroot environment might also be a good idea.

Yes but then you have to move all the dependencies in there too, like if your scripts use perl, you have to have another perl installation down there. It's easy to chroot things like ftp and bind because they have few external dependencies, doing it to Apache would probably be more trouble than it's worth. >>



BIND I believe includes chrooting availble by default. Apache can be done, but its not easy. Thanks for clearing that up

 

[nuttervm]

<<

<< I dont think Apache does this by default, but setting up a chroot environment might also be a good idea.

Yes but then you have to move all the dependencies in there too, like if your scripts use perl, you have to have another perl installation down there. It's easy to chroot things like ftp and bind because they have few external dependencies, doing it to Apache would probably be more trouble than it's worth. >>



BIND I believe includes chrooting availble by default. Apache can be done, but its not easy. Thanks for clearing that up >>



in openbsd both bind and apache are chrooted by default. apache is started under the user/group www at least thats what ps tells me

 

[n0cmonkey]

<<

<<

<< I dont think Apache does this by default, but setting up a chroot environment might also be a good idea.

Yes but then you have to move all the dependencies in there too, like if your scripts use perl, you have to have another perl installation down there. It's easy to chroot things like ftp and bind because they have few external dependencies, doing it to Apache would probably be more trouble than it's worth. >>



BIND I believe includes chrooting availble by default. Apache can be done, but its not easy. Thanks for clearing that up >>



in openbsd both bind and apache are chrooted by default. apache is started under the user/group www at least thats what ps tells me >>



I know BIND is chrooted by default (set it up at home to work on my BIND skills), but apache is not. It starts as root, binds to port 80, and drops down to uid/gid www. Its not actually chrooted, although I saw an article fairly recently about chrooting it I think. Too much work for me right now (in the middle of everything else), but if you really want to secure the system as well as possible (and you arent on a multi-user system requiring user sites) chrooting would be a nice thing to play with atleast.

 

[nuttervm]

i didnt realize that a chrooted daemon wasn't allowed to start as root. i'm kinda surprised that bind does everything without needing root access in the beginning. i guess it is a matter of how many files it needs to access, since bind (in theory) is simple and doesnt require that much whereas apache is more complicated.

on a side note, i installed the ntpd port tonite for sh!ts and giggles, and it tells me i need to reboot for it to take effect! apparently the process can't be started in the default secure runlevel and needs to be started under a lower level during boot. nothing can be perfect and all that, not even openbsd, but i'm not going to sacrifice my openbsd 3.0 month long uptime for a stupid service i don't really need

 

[n0cmonkey]

<< i didnt realize that a chrooted daemon wasn't allowed to start as root. i'm kinda surprised that bind does everything without needing root access in the beginning. i guess it is a matter of how many files it needs to access, since bind (in theory) is simple and doesnt require that much whereas apache is more complicated. >>



chrooted daemons still start as root, but it locks them into a smaller area. You have to include all the libraries used by the program in the proper places and whatnot. Look at the linux/FreeBSD emulation on OpenBSD. I think chrooting is similar to that. You have to have everything the program needs in that "virtual root" instead of just in the main system.



<< on a side note, i installed the ntpd port tonite for sh!ts and giggles, and it tells me i need to reboot for it to take effect! apparently the process can't be started in the default secure runlevel and needs to be started under a lower level during boot. nothing can be perfect and all that, not even openbsd, but i'm not going to sacrifice my openbsd 3.0 month long uptime for a stupid service i don't really need >>



I think my uptime is like 2 days. I just rebuilt the source tree to be up to -stable. And I may be shutting it down soon to switch my video cards around. Im planning on using Debian as my desktop so OpenBSD can play strictly server roles right now. The Debian machine doesnt do much anyhow

 

[DirtylilTechBoy]

What is CHROOT??

Thanks,

J

 

[Nothinman]

What is CHROOT??

When you chroot something you force it to use another directory as it's root, like if your ftp server is chrooted to /var/ftp, whenever it accesses / it's really accessing /var/ftp. It makes it harder (not impossible though) to access any files outside the chroot.