Quote:
Originally Posted by neocontrol
makes me assume that there is something like that builtin to the latest kernel.....right?
|
You know what they say about assuming things, right?..
Quote:
Originally Posted by neocontrol
I haven't found a common way to lock them down to what ports their apps can run on. Ideally I'd like to setup their users to have access to bind to ports x - y and that's it. The system I would hope would reserve that range as well, so others or the system itself can't bind to them.
|
The only "system default" is that allowing an application to bind to a port below 1024 requires root account rights (capability NET_BIND), meaning any user can have an app bind to ports over 1024. If you need to "reserve" and be able to assign a port range on a per user basis you first need to take away all or control all port binding actions (the "that what is not allowed is forbidden" mantra) before being able to assign ranges.
Running CentOS means you by default have a SE Linux-enabled kernel. SE Linux allows you to control restrictions by deploying a policy. With the default "targeted" policy unprivileged users by default remain in unconfined_t (which allows too much), so as far as I know this would mean getting each user out of unconfined_t and into it's own username_t domain before you can apply restrictions. The only example I can think of is Dan Walsh' work on Fedora's Xguest SE Linux policy which is (or should be) part of Fedora 9. If it isn't there then his web log has the basic instructions to confine a user. Another way could be to put each
user application in it's own applicationname_t, but that would get bothersome maintenance-wise very soon if you're dealing with 30 users and 10 different applications... SE Linux also has network extensions, it can police traffic based on rules, but I can't comment on that because I haven't used it (yet). Back to the initial SE Linux username_t domain idea: you have to investigate if such a policy would allow you to specify a per user range.
Another other kernel patch is GRSecurity. It can coexist with SE Linux but I haven't tried enabling both at the same time myself (slimm069 or unixfool might have). GRSec strenghtens the kernel considerably, reinforcing chroots, adding PAX and allowing control through a host of sysctls like allowing a user to only listen, only bind, or both or none, restrict users to execute apps only inside $PATH, etc, etc. GRSec can applies ACL's. Part of an ACL allowing an application to only bind to port 20000 could look like:
Code:
/some/app oXA {
/
-CAP_ALL
+CAP_NET_BIND_SERVICE
bind {
0.0.0.0/0:20000 stream tcp
}
}
Obviously this is application-centric, so here you also would have to investigate if a policy can be applied to users apps (say by wilcarding paths) and would allow you to specify a per user range.
The third kernel patch is TOMOYO (
http://tomoyo.sourceforge.jp/). It can coexist with SE Linux and enabling both at the same time works well for me ensuring I keep the protection SE Linux offers. Tomoyo is path-based and to me looks like an "easier" way (configuration-wise) to restrict things on top of SE Linux. Like GRSecurity it allows you to enable "learning mode" but also allows you to
select specific domains to put in restricted mode, which makes testing and applying easier. Part of an ACL allowing an application to only bind to port 20000 could look like:
Code:
<kernel> /sbin/init /home/user/bin/bash /some/app
use_profile 1
allow_capability inet_tcp_create
allow_capability inet_tcp_listen
allow_network TCP bind 0.0.0.0 20000
Applying a ruleset to a user seems tricky (needs something in the user's path as hook) but applying a policy to a whole users domain should work. I
thought port ranges should work but I'm not entirely sure (still playing with it). While the project is japanese in origin the documentation is in english and quite well-written and a user mailing list in english is available.
Finally, and while not a "true" restriction comparable to those mentioned above, maybe you could default DROP traffic in Netfilter and only -j REDIRECT where it matches and port and UID. Maybe if options won't work for you on their own, they may work when combined. Also if you're loaded wrt CPU and RAM then virtualisation may hold some answers as well. In any case I should emphasise this was not meant as an answer but more an exploration of options (I know of) for you to base further research on. HTH and let us know what you've decided to use. Especially if it's something not listed here.
