Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here. |
Notices |
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.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
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.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
 |
09-20-2005, 02:03 PM
|
#1
|
LQ Newbie
Registered: Apr 2004
Location: San Diego Ca/Memphis Tn
Distribution: gentoo
Posts: 13
Rep:
|
User based port "binding"
Is there any way, to limit user ability bind port(s) on a per user basis?
Example:
User joe is allowed to bind ports 4000 and 4001
User mike is allowed to bind ports 4006
i.e mike cannot bind port 0-4005;4007-infinity.
The problems I foresee here, SYSTEM daemons that run as the user, wont be able to grab on a port.
But the point of setting up this limitation, is because i plan on freely hosting muds. I have to assign users ports for their mud(s) and i do not want them futzing with each others ports.
I set up the machine for one particular mud, but, it's not like the box is earing it's gravy, a mud is not exactly cpu intensive, and i have PLENTY of bandwidth to spare.
<all account names are fictional>
Also, how else can a port be opened, other than bind?
I tried searching on this, but got nothing informative.
I mean what's the point of tweaking SUID/SGID bits, quota's and limits, killing icmp, and ssh, ectra, to harden your "server" from the inside out, just to find out dude is running a irc relay?
Yes, i COULD set up a nice firewall, and drop the type's of traffic that "negative" activities could generate, but i'd rather kill 2 birds with one stone, and discourage initial deviations to get around my security. I'd Rather have absolute control, I am the Admin.
Maby i'll need to write a pam module *shrug*
Bottom like is that i can NOT control what code users want to run as a user, but i can keep it from acting as a server.
PLus the people that are going to be using my network(s), are coders!
I thank you all beforehand for your comments, and time. No one is paid to be here.
Last edited by g33sp0t; 09-20-2005 at 02:48 PM.
|
|
|
09-20-2005, 02:39 PM
|
#2
|
LQ Guru
Registered: Nov 2004
Location: San Jose, CA
Distribution: Debian, Arch
Posts: 8,507
Rep: 
|
I've been on both sides of the table you have here. I used to run a MUD and have adminned a MUD server. It can be trying at times, so I completely understand where you are coming from.
By default, Linux (and unices) allow root to bind to ports < 1024, and all users to bind to ports > 1024. Even with SELinux, I am not aware of any technique that would make what you want to do possible. You could probably write a daemon using netstat that would kill any processes bound to ports they should not be on. It's a bit of a hack, but it's all I can think of.
Fortunately, my users were all very honest. The few times they ended up on the wrong ports were usually bugs or typos on their part.
|
|
|
09-20-2005, 02:44 PM
|
#3
|
LQ Newbie
Registered: Apr 2004
Location: San Diego Ca/Memphis Tn
Distribution: gentoo
Posts: 13
Original Poster
Rep:
|
;)
oh yes, i already have a script ready for backup 
basically a netstat and zaps a pid -9 from a ps.
And, the script that makes sure the script is running :P
The script works, but, it's not satisfactory.
I want a user to see a big "cannot bind port x : permission denied" :P i.e quit jerking around
|
|
|
09-20-2005, 02:51 PM
|
#4
|
LQ Guru
Registered: Nov 2004
Location: San Jose, CA
Distribution: Debian, Arch
Posts: 8,507
Rep: 
|
Understandable, but I think that would require a kernel hack of some sort. Might be a bit bad. 
|
|
|
09-21-2005, 04:01 AM
|
#5
|
Member
Registered: Jun 2005
Posts: 542
Rep:
|
There's an iptables module that let's you setup rules with uid checking (when possible). It's "-m owner", check iptables(8)
Also, how else can a port be opened, other than bind?
With a sniffer, using port knocking - like tricks
|
|
|
07-25-2006, 10:30 AM
|
#6
|
LQ Newbie
Registered: Jul 2006
Location: Copenhagen, Denmark
Distribution: Ubuntu 10.10
Posts: 4
Rep:
|
i realize this is digging up a very old thread, but i am looking for the same solution - binding a user to a range of ports - and iptables might just do the trick. in fact, a combination of using iptable's multiport module and owner module should work.
so before i try and "re-invent the wheel", has anyone written a good iptables setup or rule that would, for example, allow user joe to only use port 6000 and 6001 for hosting his MUD(s)?
thanks for you time!
|
|
|
07-25-2006, 12:23 PM
|
#7
|
LQ Guru
Registered: Nov 2004
Location: San Jose, CA
Distribution: Debian, Arch
Posts: 8,507
Rep: 
|
Oddly enough, I imagine you'd have to place this in the output chain. For example,
Code:
iptables -A OUTPUT -m owner --uid-owner <USERID> -p tcp -m multiport ! --sports 6000:6001 -j REJECT
This will reject any outbound tcp packets owned by <USERID> not on port 6000:6001. You should probably have a rule above this one to allow all ssh traffic back out, because on most installations, ssh processes become owned by the user.
|
|
|
07-26-2006, 04:44 AM
|
#8
|
LQ Newbie
Registered: Jul 2006
Location: Copenhagen, Denmark
Distribution: Ubuntu 10.10
Posts: 4
Rep:
|
Quote:
Originally Posted by Matir
Code:
iptables -A OUTPUT -m owner --uid-owner <USERID> -p tcp -m multiport ! --sports 6000:6001 -j REJECT
This will reject any outbound tcp packets owned by <USERID> not on port 6000:6001. You should probably have a rule above this one to allow all ssh traffic back out, because on most installations, ssh processes become owned by the user.
|
looks exactly what i am looking for, thanks Metir!
i see a ! after multiport - was that to call attention to that area, or some sort of 'not' modification to sports - "if the packets from UID are *not* leaving the box via ports 6001:6001 then drop 'em" - sort of logic?
agreed on the 'rule above this one to allow ssh' - already expected i might need to do that as well. each user needs ssh to access their account for starting/stopping their game, uploading modifications, etc.
thanks for the help!
Last edited by digitalmouse; 07-26-2006 at 05:00 AM.
|
|
|
07-26-2006, 04:44 AM
|
#9
|
Senior Member
Registered: Sep 2005
Location: Out
Posts: 3,307
Rep:
|
Maybe this
http://www.olafdietsche.de/linux/accessfs/
But I'm not sure if it works for unpriviledge ports or if it is only a way to allow users to bind to priviledge ports.
|
|
|
07-26-2006, 04:46 AM
|
#10
|
Senior Member
Registered: Sep 2005
Location: Out
Posts: 3,307
Rep:
|
Quote:
Originally Posted by Matir
Oddly enough, I imagine you'd have to place this in the output chain. For example,
Code:
iptables -A OUTPUT -m owner --uid-owner <USERID> -p tcp -m multiport ! --sports 6000:6001 -j REJECT
This will reject any outbound tcp packets owned by <USERID> not on port 6000:6001. You should probably have a rule above this one to allow all ssh traffic back out, because on most installations, ssh processes become owned by the user.
|
Ok but users are still allowed to bind any unpriviledge ports, but no traffic possible.
Or did I miss something?
|
|
|
07-26-2006, 04:58 AM
|
#11
|
LQ Newbie
Registered: Jul 2006
Location: Copenhagen, Denmark
Distribution: Ubuntu 10.10
Posts: 4
Rep:
|
as i understand it, that is exactly what is happening.
not a problem for users to run programs on any permitted port, but if those ports are not matched up with a UID in the rule example that Metri provided, the outgoing packets are rejected (dropped).
|
|
|
07-26-2006, 05:57 AM
|
#12
|
Senior Member
Registered: Sep 2005
Location: Out
Posts: 3,307
Rep:
|
Ok I though you wanted to selectively allow or refuse users to bind a port. If its for traffic then primo & matir idea is sufficient.
|
|
|
07-26-2006, 10:38 AM
|
#13
|
LQ Guru
Registered: Nov 2004
Location: San Jose, CA
Distribution: Debian, Arch
Posts: 8,507
Rep: 
|
It looks like accessfs might work for you there, but iptables sure won't. It doesn't control port binding (and can't.)
|
|
|
07-26-2006, 11:34 AM
|
#14
|
LQ Newbie
Registered: Jul 2006
Location: Copenhagen, Denmark
Distribution: Ubuntu 10.10
Posts: 4
Rep:
|
nx5000 writes: "Ok I though you wanted to selectively allow or refuse users to bind a port. If its for traffic then primo & matir idea is sufficient."
as i understand it, it's near impossible (without mucking with the kernel) to bind 'real' (aka human) users to certain ports. so the simplest hack is to just reject ports they are not allowed to use.
currently my little game hosting server works off the 'honor system': i add an account to the server, and trust them to use the port(s) i tell them they can use.
but i've already got one kid who apparently did not read my info email on the port he can use, and i noticed him using port '1337' ('leet' because he thought it was cool) instead. and i'm sure others may try to use other ports to host games 'for free' (i charge $3 to have a shell server account and use of a port for hosting their game on - this covers the server bandwidth and maintenance basically), so dropping traffic off of 'unauthorized' ports is just one method of keeping the riff-raff in line, so-to-speak.
Metir: accessfs? will have to look that one up. thanks again for the info.
|
|
|
08-02-2006, 07:58 AM
|
#15
|
Senior Member
Registered: Sep 2005
Location: Out
Posts: 3,307
Rep:
|
While looking at kernel code, I found a function selinux_socket_bind that would be good to look at. I don't have the time to investigate, I just give the pointer.
Maybe you can apply a patch there, if there is a need to.
Also:
http://www.linuxquestions.org/questi...25#post2360825
Last edited by nx5000; 08-02-2006 at 10:20 AM.
|
|
|
All times are GMT -5. The time now is 02:48 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|