Re: Allow full port access on one IP to a sub-user
From: Fredderic (fredderic@iprimus.com.au)
Date: 12/07/02
- Next message: Fredderic: "Re: Allow full port access on one IP to a sub-user"
- Previous message: John Oliver: "Re: ip-network"
- Maybe in reply to: Fredderic: "Re: Allow full port access on one IP to a sub-user"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
From: "Fredderic" <fredderic@iprimus.com.au> Date: Sat, 7 Dec 2002 13:32:51 +1000
"Mike" <mike@kamloopsbc.com> wrote in message
Errr..... According to your next message, you wrote this one to me?
Without any quoting or greeting, I have no idea what I said to bring you to
write this reply, or even that it was a reply to me until I read your next
post, and subsequently went back and dredged up the old headers to fill in
the thread tree (the message you were replying to had already been purged,
altering the way the messages are chained together in a sometimes strange
manner)...
All I can say is it doesn't seem to fit anything I may have suggested.
> That's an interesting angle... Could it be as simple as having the
> machine know to translate a public IP into a private IP:
> That way root priveleges are not required to install or run the
> apache, ftp or ssh daemons.....
I'm trying to figure out what relavance having root is to this discussion.
Certainly that would do what you suggest, however it would take root
privelage to create the redirection in the first place, and I'm not sure
that a private IP is even at all relevant. You could theoretically
translate the port number in place.
The original issues you seem to be referring to are:
> 1) decisions based on the executable being run (preferably by
> converting PID to device/inode, and looking it up in a "compiled" list
> built from a list of filenames and their permissions, and preferably
> llowing a bunch of executables to optinally be grouped together)
This means that when an incoming packet hits the rule, the firewall examine
the listening socket list to see which process owns it. It then looks up
the resulting PID to determine (effectively) the actualy binary that was
run.
This would allow, for instance, a set of "official software" which could
safely be started by the user, and allowed to open arbitrary ports as it
sees fit (knowing already that there aren't going to be any unwanted
security side effects, or it wouldn't have been added to the list in the
first place).
The conversion to device/inode was essentially an optimisation to prevent
the possibility of having umpteen-odd great big long filenames stored in
kernel memory, and then having to reduce both the name obtained from the PID
and/or the ones from the list to their cannonalized form prior to
comparison. This way you're only storing a fixed 4 to 8 bytes (I think) per
allowed file with a little extra administrative data.
> 2) decisions based on username (uid) and/or group (gid).
This is very similar, requiering a conversion to PID, then accessing the
relevant tables to determine the effective UID and GID running the process.
This would allow for instance, a set of "administrative" users to run
processes under their own user without having to drop to root, while denying
other users from doing this (as opposed to your idea which would allow
anyone to start a given server, should the original go down for some
reason).
Of course, as someone pointed out at some time or another, either of these
are really relevant only if:
A) the server and firewall are on the same machine or
B) we have some protocol in place to transport the listening sockets PID,
UID, and/or GID and any other information we deem appropriate.
Option B could be served by a firewall module which is able "hold" a packet
until it's destination can be verified by way of the auth demon (port 113).
However doing this every single time a packet comes through would make for
some really huge internal traffic and so you'd need to "cache" the replies.
However you'd still need to poll the port periodically to check that it's
still there, and this could mean a race condition in which the original
server closes, and a user is able to substitute their own for up to, the
auth poll period. Or, even worse, they may be able to find a way to
interfere with the polling by tying up the auth demon itself, therefore
giving themselves free reign.
It would require more likely some kind of demon on the remote machine which,
once connected as above, would keep a constant vigil on the process in
question and not only report that it was there ala auth, but report also
when it closes so the firewall could flush the corresponding cache entry.
Actually, an alternative method which wouldn't require a new iptables
module, would be to run a daemon on the firewall which accepts an auditing
log from the remote machine, including within it entries for "process
started on pid x by user y and group z", "process x finished on pid x", and
"process on pid x listening on port y". The daemon could then poke holes in
the firewall as appropriate. However on a normal system that would be an
awful lot of log entries, especially say, when running a long shell script.
So again you'd need a specialised remote daemon which might, for instance,
monitor listening port creations and destructions, and send the relevant
information.
- Next message: Fredderic: "Re: Allow full port access on one IP to a sub-user"
- Previous message: John Oliver: "Re: ip-network"
- Maybe in reply to: Fredderic: "Re: Allow full port access on one IP to a sub-user"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ] [ attachment ]
Relevant Pages
|
