Re: Just a wild idea

[Julian Elischer]

On Sat, 28 Sep 2002, Nielsen wrote:

> IPFW's forwarding feature can be used for transparent proxying on another
> machine. To do it on the same machine, you'd probably need to use NAT.



no you can use fwd on thesame machine too.

just fwd to a local address.

> 
> Nate
> 
> > I haven't actually tried this, but shouldn't it be possible
> > to use IPFW's forwarding feature for that?  For example,
> > let sendmail run on port 2500 and then add ipfw fwd rules
> > to forward between ports 2500 and 25.
> >
> > Regards
> >Oliver
> 
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-hackers" in the body of the message
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[Nielsen]

IPFW's forwarding feature can be used for transparent proxying on another
machine. To do it on the same machine, you'd probably need to use NAT.

Nate

> I haven't actually tried this, but shouldn't it be possible
> to use IPFW's forwarding feature for that?  For example,
> let sendmail run on port 2500 and then add ipfw fwd rules
> to forward between ports 2500 and 25.
>
> Regards
>Oliver



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[Oliver Fromme]

Sorry for the late reply (I don't skim through the hackers
list very often).

Paul Schenkeveld <[EMAIL PROTECTED]> wrote:
 > 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.

I haven't actually tried this, but shouldn't it be possible
to use IPFW's forwarding feature for that?  For example,
let sendmail run on port 2500 and then add ipfw fwd rules
to forward between ports 2500 and 25.

Regards
   Oliver

-- 
Oliver Fromme, secnetix GmbH & Co KG, Oettingenstr. 2, 80538 München
Any opinions expressed in this message may be personal to the author
and may not necessarily reflect the opinions of secnetix in any way.

"All that we see or seem is just a dream within a dream" (E. A. Poe)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[Mikko Työläjärvi]

On Tue, 24 Sep 2002, Paul Schenkeveld wrote:

> Hi Thomas,
>
> On Tue, Sep 24, 2002 at 01:31:59AM +0200, tho wrote:
> > hi Paul,
> >
> > have you considered using a "file descriptor passing" based technique
> > (section 14.7 of Stevens' UNPv1) ?
> >
> > you may have a process with suser privs which creates file descriptors
> > (e.g. socket bind()ed to a particular address and port) on demand and then
> > passes back the descriptor to the requesting (unprivileged) process through
> > a unix domain socket
>
> I know this technique but the real issue is about many pieces of
> standard software, like BIND named, sendmail, syslogd and so on.
> So this technique, although very usable for new projects, will
> not solve this problem.

As long as the programs are dynamically linked, you can LD_PRELOAD a
wrapper for bind() that passes the socket and address information to
the privileged process that does the actual bind() call and replies
with an errno value.

It works.  I've done it.

  $.02,
  /Mikko

 Mikko Työläjä[EMAIL PROTECTED]
 RSA Security


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[Brian T. Schellenberger]

You can get a somewhat similar effect right now (that is, root being not 
permitted to mess with your files) by using "cfs."

Ok, true, root can still destroy your files by using the underlying 
"real" file system, but he can't view or manipulate them in their 
plaintext form.

I must say that when I first installed cfs I was quite taken aback when, 
as root, I encountered this:

   i8k# ls /c/bts
   ls: bts: Operation not permitted
   i8k#

Of course, it's not at all the same thing, really--root just has to 'su' 
to the ordinary user and then he gains privileges to the file, but you 
can never at one moment have the power of root *and* access to the 
files in the cfs file system.  (Unless root is the one attached to 
them, of course.)


On Tuesday 24 September 2002 04:09 am, David P. Reese Jr. wrote:
| On Mon, 23 Sep, 2002, Lamont Granquist wrote:
| >> 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.
| >
| >Something like that sounds like a really good idea.  I'd like to see
| > this not only for binding to low ports but also, for example, to
| > set the system time -- this would let you run ntpd as non-root.
| >
| >It'd be interesting to have a system one day where once you've gone
| > past single user mode, root drops all its privs and acts just like
| > a normal user account and daemon accounts only have special privs
| > handed out to them in little chunks.
|
| This is starting to sound a bit too much like Plan9.  Here is a very
| short snippit on filesystem permissions from the document at:
| http://plan9.bell-labs.com/wiki/plan9/KFS_file_system_configuration/i
|ndex.html
|
| [snip]
| There is no super-user; the closest equivalent is the person who
| booted the terminal (generically called Eve; Adm owns the file
| server). Most devices are owned by Eve, and the local kernel will let
| Eve do most things commonly associated with a super-user (for
| example, debug or kill processes she doesn't own). Eve's power does
| not extend past the local machine, though, or even into the kfs file
| system. The important difference is that the kfs file system is being
| provided by a user process, which has its own permissions checking
| separate from the kernel, and it does not care to let the hostowner
| have special permissions directly.
| [snip]

-- 
Brian, the man from Babble-On . . . .   [EMAIL PROTECTED] (personal)

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[David P. Reese Jr.]

On Mon, 23 Sep, 2002, Lamont Granquist wrote:
>> 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.
>
>Something like that sounds like a really good idea.  I'd like to see this
>not only for binding to low ports but also, for example, to set the system
>time -- this would let you run ntpd as non-root.
>
>It'd be interesting to have a system one day where once you've gone past
>single user mode, root drops all its privs and acts just like a normal
>user account and daemon accounts only have special privs handed out to
>them in little chunks.

This is starting to sound a bit too much like Plan9.  Here is a very short
snippit on filesystem permissions from the document at:
http://plan9.bell-labs.com/wiki/plan9/KFS_file_system_configuration/index.html

[snip]
There is no super-user; the closest equivalent is the person who booted the
terminal (generically called Eve; Adm owns the file server). Most devices are
owned by Eve, and the local kernel will let Eve do most things commonly
associated with a super-user (for example, debug or kill processes she
doesn't own). Eve's power does not extend past the local machine, though, or
even into the kfs file system. The important difference is that the kfs file
system is being provided by a user process, which has its own permissions
checking separate from the kernel, and it does not care to let the hostowner
have special permissions directly. 
[snip]

-- 

   David P. Reese Jr.  [EMAIL PROTECTED]
   --
   C 
  You shoot yourself in the foot. 
   Assembler
  You try to shoot yourself in the foot, only to discover you must first
  invent the gun, the bullet, the trigger, and your foot. 

How to Shoot Yourself in the Foot


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[Paul Schenkeveld]

Hi Thomas,

On Tue, Sep 24, 2002 at 01:31:59AM +0200, tho wrote:
> hi Paul,
> 
> have you considered using a "file descriptor passing" based technique
> (section 14.7 of Stevens' UNPv1) ?
> 
> you may have a process with suser privs which creates file descriptors 
> (e.g. socket bind()ed to a particular address and port) on demand and then 
> passes back the descriptor to the requesting (unprivileged) process through 
> a unix domain socket

I know this technique but the real issue is about many pieces of
standard software, like BIND named, sendmail, syslogd and so on.
So this technique, although very usable for new projects, will
not solve this problem.

> tho

Thanks for your answer,

Paul Schenkeveld

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[Michał Belczyk]

On Sun, Sep 22, 2002 at 04:14:53PM +0200, Paul Schenkeveld wrote:
> 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.
> 
Exactly. It would be great to have the capabilities implemented
in -stable ;)
I've written a kernel module for -stable You may be interested in.
With it You can for example let specified euids bind to the reserved
TCP/UDP ports. It's fully managed via sysctl. It also doesn't affect
jails. It's still under development but I use it e.g. to let my non-root
chrootuided syslogd bind to its port :)
All the effort is in fact
sysctl fgc.net_bind.udp.acl=[60514:514]
where 60514 is syslogd user's uid.
The crazy syslogd story is here: http://bsd.krakow.pl/syslogd.html and
the fgc sources.. cvs -d:pserver:[EMAIL PROTECTED]:/cvs/fgc co fgc

You may also consider using the TrustedBSD-cap stuff and give the
syslogd binary CAP_NET_BIND_SERVICE capability.. but that's still
-current.

Another possibility of giving a regular user some of the superuser
powers is CerbNG (http://cerber.sourceforge.net), but I'm not sure if
Pawel has already implemented the bind() stuff..
It's definetely more advanced and more complete security solution for
-stable than my per euid/per group capabilities and it's also still
under development. With that You can create per binary security policies
including restricting access to selected syscalls and granting additional
access to other, superuser-reserved syscalls.
.. and probably many other things that I'm not aware of :))


-- 
Michał Belczyk



msg37008/pgp0.pgp
Description: PGP signature

Re: Just a wild idea

[Juli Mallett]

* De: Lamont Granquist <[EMAIL PROTECTED]> [ Data: 2002-09-23 ]
[ Subjecte: Re: Just a wild idea ]
> 
> On Sun, 22 Sep 2002, Juli Mallett wrote:
> > 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.
> 
> Something like that sounds like a really good idea.  I'd like to see this
> not only for binding to low ports but also, for example, to set the system
> time -- this would let you run ntpd as non-root.
> 
> It'd be interesting to have a system one day where once you've gone past
> single user mode, root drops all its privs and acts just like a normal
> user account and daemon accounts only have special privs handed out to
> them in little chunks.

One day?  It's really easy to do, especially once you have a way for init
to set privs for the children easily, and you can just have your rc scripts
work with init.
-- 
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

[Lamont Granquist]

On Sun, 22 Sep 2002, Juli Mallett wrote:
> 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.

Something like that sounds like a really good idea.  I'd like to see this
not only for binding to low ports but also, for example, to set the system
time -- this would let you run ntpd as non-root.

It'd be interesting to have a system one day where once you've gone past
single user mode, root drops all its privs and acts just like a normal
user account and daemon accounts only have special privs handed out to
them in little chunks.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[Bruce M Simpson]

On Mon, Sep 23, 2002 at 08:29:15AM +0200, John Hay wrote:
> > 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

I remember around 6 years ago, when I still ran Linux, that the solution
to this problem came in the form of a diff which delegated bind() on
a reserved port credentials to a certain GID, BIND_GID. From that point on,
the boot process had to be changed such that daemons which only needed to
bind to a privileged port were run under their own non-root uid, with this
BIND_GID in the additional groups list, using a wrapper such as sudo.

This still amounts to a local mod - it can be done, has been done before,
I think Tom Ptacek did some diffs for this for vanilla 4.4BSD a good while
back, rewriting it for your current tree can't be too difficult.

See here: http://www.sockpuppet.org/tqbf/sysctlpriv.html

BMS

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message

Re: Just a wild idea

[John Hay]

> > > 
> > > 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

Re: Just a wild idea

[Julian Elischer]

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

[Juli Mallett]

* 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

Just a wild idea

[Paul Schenkeveld]

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