1

The organization I work for is very security-minded. There is a separation between the group of System Administrators who are responsible for the operating systems (who, obviously, have root) and those of us who maintain the services that run on those operating systems (of which I would be one, and we are not to have access to root except constrained via sudo).

I am currently in the process of redesigning how we maintain our Apache configuration. The new setup will be running on RHEL, where the old ran on Solaris.

Somehow, under Solaris, when piped logging was used, the scripts to which the log was piped ran as the same user as Apache, that being webservd. Under RHEL, however, they end up running as root, where I would have preferred that they run as the apache service account (i.e. apache, the same account where the actual Apahce services get spawned).

Solutions that involve using sudo in the pipe call aren't sufficient; before I'll be allowed to move this past QA, I'll need to come up with a way to make it so that you can't cause something to run as root by putting it into the Apache config files. I suspect that the solution involves granting the apache user some special priviliges (so that it can bind to ports 80/443) and then using that rather than root to start the service.

Any help would be greatly appreciated.

Addendum: A request was made that I show how the piped log is called.

This is the relevant line from the configuration file: 

CustomLog "||/httpd/scripts/syslog.py" qradar

What ends up happening is that the script at /httpd/scripts/syslog.py ends up running as root. We need to make this not only not happen, but also not possible to do.

Improve this question
2
  • Please specify how you configured the logging and started the pipe so as to help us to find a solution.
    – Ned64
    Jun 24, 2015 at 13:47
  • Can do. I just put an addendum on the bottom of the question with the info you requested.
    – Glenn Lasher
    Jun 24, 2015 at 19:45

1 Answer 1

Reset to default
1

If I understand you correctly, you simply don't want to run HTTP as root. Either don't have Apache listen to port 80 and use IPtables to redirect those packets to a higher port number; or tell Linux that ports < 1024 are not secure. See the excellent answer at https://unix.stackexchange.com/a/10791/105631. Also here: https://stackoverflow.com/a/414258/3849157

A custom kernel isn't a bad idea. Many people have noted that the 1024 restriction is antiquated and security-wise, obsolete. An answer was provided to a similar question in which the kernel is patched so that PORT_SOCK is changed from 1024 to 24. https://stackoverflow.com/a/27989419/3849157

Improve this answer
6
  • 2
    I like the idea of redirecting by IPTables. Actually, that gave me another idea, specifically that I should check with the networking team to see if they can just throw it to me on a different port at the load balancers. Thank you for that.
    – Glenn Lasher
    Jun 24, 2015 at 15:23
  • Yes, that seems like a good solution! A popular alternative port is 8080 (see grc.com/port_8080.htm but I think you may know this anyway). It could be re-mapped in your router.
    – Ned64
    Jun 24, 2015 at 19:59
  • 1
    A custom kernel for the sole purpose of changing this variable is hardly a good idea, because it tends to impose an additional burden on the admin - whenever the kernel packages get updated for security updates, and that sort of thing happens quite often these days, they can't just quickly upgrade, they have to repeat the patching and recompiling and verifying that everything still works. Since Glenn already told us he's not part of the group who could be doing that, the idea seems completely off base.
    – Josip Rodin
    Jun 24, 2015 at 20:34
  • Another reason why the restriction isn't necessarily obsolete is if you have layered security - if there are network firewalls in front of the server that block any attempts to open outside connections to any listeners on ports above 1024, that means that attackers can't just compromise any user account and bring up a new listener, they would have to compromise some specific, limited subset of accounts that control specific binaries with the capabilities that allow them to bring up listeners on specific ports. And those accounts, in turn, would presumably be defended more thoroughly.
    – Josip Rodin
    Jun 24, 2015 at 20:45
  • I dont consider paper-thin layers as real layers. Besides, as noted by the actual problem, it's a poor tradeoff : to run such a service, full root-access is required, which imposes more security risks and burdens. Eliminating the restriction but adding port-user-specific (ie, SELinux) enforcement would be the better, layered choice.
    – Otheus
    Jun 25, 2015 at 8:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.