Just a wild idea
Hi All,
I've been playing with jails for over 2 years now. I really like
them but we often use them to run a process as root with reduced
power only to get access to TCP and UDP ports below 1024.
For many applications however, for example lpd, named, sendmail,
tac_plus and others, it would be more than good enough to run that
program as a normal, non-root user provided there is a way to bind
to that single low TCP and/or UDP port that the program needs access
to.
So I was wondering if we couldn't come up with a method to allow the
startup of a normal non-root process with the only increased power
of being able to bind to a specific port. This would be the opposite
of jail which allows the startup of a program as root and then tries
to revoke many powers.
I envision a system call (only accessible to root) that will grant
bind access to a single TCP or UDP port, which will persist even
after set*[ug]id calls and will be inherited by child processes and
a very small setuid root wrapper program to exercise that system
call, become a non-root user and then exec the real program.
The synopsis for the system call could be something like this:
int portaccess(int version, int protocol, const struct sockaddr *addr);
where version works like with jail, protocol is either IPPROTO_TCP or
IPPROTO_UDP and the addr structure holds the port number (1 .. 1023)
and either INADDR_ANY or the ip address of one of the interfaces.
Multiple calls should accumulate access rights so programs like bind
could get access to both a UDP and TCP port.
The wrapper program then should be something like:
portaccess [-i user:group] -{u|t} [address:]port ... cmd args
Where -i selects the identity obtained after all portaccess system calls
have been made (nobody/nogroup if omitted) and -u and -t add access to a
single port. Finally if all portaccess and set*[ug]id calls have been
made an no error occured, execv is called with the remaining arguments
starting at cmd.
I understand that implementing this has quite some impact as we would
have to carry around all accumulated access rights in or near the proc
structure, the fork and exec calls need to be aware of this extra data
and the bind system call needs to do additional checking before refusing
access to a low TCP or UDP port but I think it's worth the efford.
I still like jail(2) and jail(8) very much for bigger purposes like
virtual hosts for shell logins or web hosting but I feel they are too
heavy for small problems like named which only needs access to UDP and
TCP ports 53 but can do everything else as a normal user.
Any thoughts? Am I inventing something nobody is waiting for? Is
something going on already that I am not aware of?
Please let me know.
Paul Schenkeveld, Consultant
PSconsult ICT Services BV
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
YES, FREE MORTGAGE 4% QUOTES WITH NO CLOSING COSTS!
Below is a Heartfelt Crest Request. It was submitted by [EMAIL PROTECTED] ([EMAIL PROTECTED]) on Sunday, September 22, 2002 at 18:25:09 --- 4b: DONT GET A MORTGAGE UNTIL YOU READ THIS FIRST! Important information on mortgage rates. FREE INFORMATION AT THE LINK BELOW. http://www.lendingmort.com";>CLICK HERE FOR MORE INFORMATION 21fh --- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Just a wild idea
* De: Paul Schenkeveld <[EMAIL PROTECTED]> [ Data: 2002-09-22 ] [ Subjecte: Just a wild idea ] > Hi All, > > I've been playing with jails for over 2 years now. I really like > them but we often use them to run a process as root with reduced > power only to get access to TCP and UDP ports below 1024. > > For many applications however, for example lpd, named, sendmail, > tac_plus and others, it would be more than good enough to run that > program as a normal, non-root user provided there is a way to bind > to that single low TCP and/or UDP port that the program needs access > to. The problem is that suser(9) sucks. I had a nice system which used gids and fell back to uid0, but the gids were sysctl tunables, and were very fine-grained (in as much as they could be), and uid0 could be disabled. I don't have it anymore, but it's pretty trivial to implement. Lots of people want suser(9) to die, and I have spoken a bit with rwatson@ on this subject, and I seem to recall that with the intro of MAC, he had some ideas for killing off suser(9)... Maybe just replace all suser(9) uses with MAC credential checks, and install MAC_UNIX by default, which would be set up to behave like ye olden UNIX... Who knows. Anyway, your idea strikes me as not generalised enough to justify itself. In a "local FreeBSD mods" way, it might do the job great for you, but a more generalised approach is likely better. You are picking one of the symptoms of the problem of UNIX historically having this admittedly-thick security methodology and working around the problem. Attacking the problem is likely to be easier, and more elegant, too :) juli. -- Juli Mallett <[EMAIL PROTECTED]> | FreeBSD: The Power To Serve Will break world for fulltime employment. | finger [EMAIL PROTECTED] http://people.FreeBSD.org/~jmallett/ | Support my FreeBSD hacking! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Just a wild idea
On Sun, 22 Sep 2002, Juli Mallett wrote: > * De: Paul Schenkeveld <[EMAIL PROTECTED]> [ Data: 2002-09-22 ] > [ Subjecte: Just a wild idea ] > > Hi All, > > > > I've been playing with jails for over 2 years now. I really like > > them but we often use them to run a process as root with reduced > > power only to get access to TCP and UDP ports below 1024. > > > > For many applications however, for example lpd, named, sendmail, > > tac_plus and others, it would be more than good enough to run that > > program as a normal, non-root user provided there is a way to bind > > to that single low TCP and/or UDP port that the program needs access > > to. better to have a definition of what are restricted ports for each jail than to redefine what root is (1024 numbers is only 32 words of bitmask) (just my opinion) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Just a wild idea
> > > > > > I've been playing with jails for over 2 years now. I really like > > > them but we often use them to run a process as root with reduced > > > power only to get access to TCP and UDP ports below 1024. > > > > > > For many applications however, for example lpd, named, sendmail, > > > tac_plus and others, it would be more than good enough to run that > > > program as a normal, non-root user provided there is a way to bind > > > to that single low TCP and/or UDP port that the program needs access > > > to. > > better to have a definition of what are restricted ports for each jail > than to redefine what root is > > (1024 numbers is only 32 words of bitmask) Sometimes I think the below 1024 check is outdated. What about a flag to switch the below 1024 check totally off? How much do we really loose? The two most common setups are probably a single user desktop and a server box doing something like mail, web or dns. On the desktop switching the below 1024 check off only gain the user (who is also root) something, he needs to su less. In a server environment, access to the box is normally controlled in anycase, so the people who have access to the box, normally also are the ones that have the root password or whatever is needed to (re)start those services. The only place where I think the check might still be usefull, is on a general shell login box. John -- John Hay -- [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
