Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Introduction to Linux - A Hands on Guide
This guide was created as an overview of the Linux Operating System, geared toward new users as an exploration tour and getting started guide, with exercises at the end of each chapter.
For more advanced trainees it can be a desktop reference, and a collection of the base knowledge needed to proceed with system and network administration. This book contains many real life examples derived from the author's experience as a Linux system and network administrator, trainer and consultant. They hope these examples will help you to get a better understanding of the Linux system and that you feel encouraged to try out things on your own.
Click Here to receive this Complete Guide absolutely free.
I wouldn't say they are more vulnerable unless they are actually doing something, just opening the port doesn't make them more vulnerable, but yes once they drop privileges they are like any other account and can only directly access what that account can access.
So in my understanding, services are really vulnerable at boot time.
Then the identity of the service is like any other account.
Vulnerable against what? Remote exploits?
Until the process binds the port, it isn't acting on any malicious data - it isn't *receiving* anything from the network until it binds the port. Once it binds the port, and is therefore "vulnerable" to remote attacks, then it *immediately* drops the root privilege. Lots of software like Apache etc. do all their setup first and then in two consecutive lines bind the port and drop privileges. Any window of opportunity is on a nano-second scale and in that moment Apache isn't doing *anything* with *any* data that arrives from a remote location.
Additionally, because the process isn't "ready" it probably denies any and all requests from external source until it knows it is "safe" to respond (i.e. it's only running as an unprivileged user).
The "privilege" that requires permission is "binding" to a port that is < 1024. Once that has occurred, the program in question is given notice whenever anything arrives on that port (including access to the data that arrived). Binding the port (asking for this notification) is the privileged operation only available to root. But once the request is in, the notifications still arrive no matter what user Apache pretends to be. Otherwise, it would be a waste of time because Apache would ever only be able to run as root.
If Apache started as root (which is what happens), bound the port it needed, dropped to "apache" (an unprivileged user) and then tried to bind that port (or anything else < 1024) again, it would fail horribly. Instead it does it once, drops all root permissions and then everything that comes into port 80 is processed as the "apache" user.
For all purposes, once it has "seteuid" (set effective user id's) to "apache", it is no different to the apache user at all and no longer has any of root's "special features" and thus it will just get "permission denied". But the only "special features" is *binding* to a port (i.e. asking for notification if data arrives there and thus being able to retrieve that data), not recieving the data itself.