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 actual
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 por
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
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 whic
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 wh
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
>n
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 part
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, f
* 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
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 fo
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
> > >
> > > 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,
> > >
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 r
* 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
14 matches
Mail list logo