[Nix <[EMAIL PROTECTED]>]
> I haven't checked this or anything, but it seems to me that all you
> need is a cooperating process outside the jail, that opens some
> world-readable directory
In that case, you are already outside. (: Why bother with the chroot
process at all?
Peter
-
To unsubscri
Hi!
> > Two easy "get out of jail free" cards. There are other, more complex
> > exploits. You have added one more. They all require root privileges.
>
> Actually, I've heard that a chrooted _non-root_ process can find another
> process with the same uid that's not chrooted and can ptrace() t
[EMAIL PROTECTED] wrote:
> Hello!
>
> > Well, because lots of people seem to THINK that chroot imprisons
> > someone. And "jail" actually does
>
> Also many of people work to add to linux jail-like functionality,
> which is expected to be real security tool unlike bsd jail.
>
> I think from
Hello!
> Well, because lots of people seem to THINK that chroot imprisons
> someone. And "jail" actually does
Also many of people work to add to linux jail-like functionality,
which is expected to be real security tool unlike bsd jail.
I think from the same source where you read about jail
[EMAIL PROTECTED] wrote:
> Hello!
>
> > This IS the magical security device.
>
> Jail maybe is. Chroot is not. It is even not clear, why you remembered
> about jail here. Chroot does not imprison anyone.
Well, because lots of people seem to THINK that chroot imprisons
someone. And "jail" actua
Hello!
> This IS the magical security device.
Jail maybe is. Chroot is not. It is even not clear, why you remembered
about jail here. Chroot does not imprison anyone.
Alexey
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Alan Cox wrote:
> > It's simply not good enough to close all directory file descriptors before
>chrooting.
> >
> > If calling chroot once you're already in a chroot jail was disallowed, it would
>stop
> > this attack.
> I think the problem here is that some people have the idea that
> chroot
Peter Samuelson <[EMAIL PROTECTED]> writes:
> Two easy "get out of jail free" cards. There are other, more complex
> exploits. You have added one more. They all require root privileges.
Unless I'm missing something, not all of them do. I haven't checked this
or anything, but it seems to me th
On Fri, Nov 17, 2000 at 12:30:00AM -0600, Peter Samuelson wrote:
> Two easy "get out of jail free" cards. There are other, more complex
> exploits. You have added one more. They all require root privileges.
Actually, I've heard that a chrooted _non-root_ process can find another
process with t
Peter Samuelson wrote:
>
> [I wrote]
> > > mkdir("foo")
> > > chroot("foo")
>
> [H. Peter Anvin]
> > BUG: you *MUST* chdir() into the chroot jail before it does you any
> > good at all!
>
> No, it wasn't a bug! It was a demonstration. The above code is
> executed not by the application
On Thu, 16 Nov 2000, H. Peter Anvin wrote:
> BUG: you *MUST* chdir() into the chroot jail before it does you any
> good at all!
>
> I usually recommend:
#include
/* for EX_NOUSER */
> mkdir("foo");
> chdir("foo");
> chroot(".");
add this:
/* DO REPLACE 500 BY AN EXISTING USER ID */
[I wrote]
> > mkdir("foo")
> > chroot("foo")
[H. Peter Anvin]
> BUG: you *MUST* chdir() into the chroot jail before it does you any
> good at all!
No, it wasn't a bug! It was a demonstration. The above code is
executed not by the application but by the *attacker* who has managed
to 0wn
Followup to: <[EMAIL PROTECTED]>
By author:Peter Samuelson <[EMAIL PROTECTED]>
In newsgroup: linux.dev.kernel
>
>
> [jesse]
> > 1. Your server closes all open directory file descriptors and chroots.
> > 2. Someone manages to run some exploit code in your process space which--
>
> mkdir(
[jesse]
> 1. Your server closes all open directory file descriptors and chroots.
> 2. Someone manages to run some exploit code in your process space which--
mkdir("foo")
chroot("foo")
chdir("../../../../../../../../../..")
chroot(".")
mkdir proc
mount -t proc none proc
cd proc/1
On Thu, 16 Nov 2000, jesse wrote:
> But the problem is because you can call chroot when you're already chrooted.
It's a non-problem. chroot()ing again may also be used to de-escalate
privileges, and if you want to prevent breaking out of a chroot, drop
root privileges, since chroot is a privileg
> It's simply not good enough to close all directory file descriptors before chrooting.
>
> If calling chroot once you're already in a chroot jail was disallowed, it would stop
> this attack.
I think the problem here is that some people have the idea that chroot is
some kind of magical security
On Thu, Nov 16, 2000 at 11:52:49AM -0800, jesse wrote:
> On Thu, Nov 16, 2000 at 05:16:18PM +0100, Andrea Arcangeli wrote:
> > On Thu, Nov 16, 2000 at 03:07:04PM +0100, Matthias Andree wrote:
> > > It shows a program that saves the cwd -- open(".",...) in an open file,
> > > then chroots [..]
> >
On Thu, Nov 16, 2000 at 05:16:18PM +0100, Andrea Arcangeli wrote:
> On Thu, Nov 16, 2000 at 03:07:04PM +0100, Matthias Andree wrote:
> > It shows a program that saves the cwd -- open(".",...) in an open file,
> > then chroots [..]
>
> This is known behaviour (I know Alan knows about it too), solu
On Thu, Nov 16, 2000 at 03:07:04PM +0100, Matthias Andree wrote:
> It shows a program that saves the cwd -- open(".",...) in an open file,
> then chroots [..]
This is known behaviour (I know Alan knows about it too), solution is to close
open directories filedescriptors before chrooting.
Everyth
On Fri, 10 Nov 2000, Alan Cox wrote:
> Ok so the PS/2 bug is real and the megaraid mystery continues
>
> Anything which isnt a strict bug fix or previously agreed is now 2.2.19
> material.
Torsten Hilbrich posted a chroot "bug" that works on 2.2.17 and
2.2.18pre21, it's in de.comp.os.unix.netwo
Oops !
better with the patch :-)
Willy
> Ok, Matti,
> here's a final patch against the bonding patch I
> posted on Friday.
___
Do You Yahoo!? -- Pour dialoguer en direct avec vos amis,
Yahoo! Messenger : http://fr.messenger.yahoo.com
pa
Ok, Matti,
here's a final patch against the bonding patch I
posted
on Friday. Could you tell me if it fits your needs ?
If so, I would repost (offline) the complete one
against 2.2.18pre21. Anyway, for those curious here,
it's available at the following URL:
http://www-miaif.lip6.fr/willy/pub/lin
> EtherChannel. Supposedly, it also supports failover
> (though even "bonding" driver docs used to say that
> was impossible because the linux networking
subsystem
> didn't handle card failures gracefully enough).
the new bonding code supports failover. It probes the
cards itself. Although this
Dan Browning wrote:
>
> I think it is great that there is continued valuable developement on the
> bonding driver. Have you guys taken a look at the source code for Intel's
> new ANS driver? For any Intel network card, it will do 8-way Fast
> EtherChannel. Supposedly, it also supports failover
I think it is great that there is continued valuable developement on the
bonding driver. Have you guys taken a look at the source code for Intel's
new ANS driver? For any Intel network card, it will do 8-way Fast
EtherChannel. Supposedly, it also supports failover (though even
"bonding" driver
Matti Aarnio wrote:
> Beowulf systems have "bonding" in use for parallel Ethernet
> links in between two machines, however THAT is not EtherChannel
> compatible thing!
>
Maybe we should adopt's sun naming then, and call it 'Trunking'.
This is the same driver that Beowulf
> I don't like to call it BONDING.
> "Bonding" is something where two (or more) channels
> carry data in between two participating systems.
> Like Multilink-PPP, and ISDN Channel Bonding. Often
> indeed data goes out somehow inter-leaved on the
> physical links. (Like ISDN Channel Bonding suppli
Le Fri, Nov 10, 2000 at 03:07:21AM +, Alan Cox a écrit:
> Anything which isnt a strict bug fix or previously agreed is now 2.2.19
> material.
Compiling 2.2.18pre21 without sysctl gives an error at linkage:
kernel/kernel.o(__ksymtab+0x608): undefined reference to `sysctl_jiffies'
trivial patc
On Fri, Nov 10, 2000 at 12:22:04PM +0200, Constantine Gavrilov wrote:
> Gee, we do not call it EtherChannel, we say CISCO calls it
> EtherChannel. Where is the infringment here? Are people that paranoid
> or it is just me who is not getting it?
You missed my original point.
I don
> > > is important. We could call it
ETHERNETCHANNEL (and even
> > > "Etherchannel" or "ETHERCHANNEL") get
away with it clean.
> > > ...
> > > /Matti Aarnio
> Anything but "EtherChannel" -- trademark people
Ok, Matti. Let's keep "Etherchannel" as you proposed
and as it
> However, it has not been tested enough that I may
bet
> by head on saying there are no known issues.
I won't say there are no issues, but I'd say there are
no KNOWN issues.
> This is because I did not have access to all
> hardware that was needed to complete the tests in
> time.
I know that,
Matti Aarnio wrote:
>
> On Fri, Nov 10, 2000 at 11:57:45AM +0200, Constantine Gavrilov wrote:
> > > Cisco Trademark is EtherChannel -- there the capitalization
> > > is important. We could call it ETHERNETCHANNEL (and even
> > > "Etherchannel" or "ETHERCHANNEL") get away
willy tarreau wrote:
>
> > Anything which isnt a strict bug fix or previously
> > agreed is now 2.2.19 material.
>
> Alan, do you consider it as a bugfix if I tell you
> that
> we can't get anymore oops with the new bonding code,
> even in SMP ?
>
> I've had reports of it working very well, and
On Fri, Nov 10, 2000 at 11:57:45AM +0200, Constantine Gavrilov wrote:
> > Cisco Trademark is EtherChannel -- there the capitalization
> > is important. We could call it ETHERNETCHANNEL (and even
> > "Etherchannel" or "ETHERCHANNEL") get away with it clean.
> > ...
> > > R
Matti Aarnio wrote:
>
> On Fri, Nov 10, 2000 at 10:28:46AM +0100, willy tarreau wrote:
>
> From the patch source:
>
> +CONFIG_BONDING
> + Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
> + Channels together. This is called 'Etherchannel' by Cisco,
> + 'Trunking' by Sun,
On Fri, Nov 10, 2000 at 10:28:46AM +0100, willy tarreau wrote:
From the patch source:
+CONFIG_BONDING
+ Say 'Y' or 'M' if you wish to be able to 'bond' multiple Ethernet
+ Channels together. This is called 'Etherchannel' by Cisco,
+ 'Trunking' by Sun, and 'Bonding' in Linux.
I thin
> Anything which isnt a strict bug fix or previously
> agreed is now 2.2.19 material.
Alan, do you consider it as a bugfix if I tell you
that
we can't get anymore oops with the new bonding code,
even in SMP ?
I've had reports of it working very well, and faster,
for a long time now and the link
Ok so the PS/2 bug is real and the megaraid mystery continues
Anything which isnt a strict bug fix or previously agreed is now 2.2.19
material.
Alan
2.2.18pre21
o Environment controller update for sparc (Eric Brower)
o No italian translation for config.help (Andrea
38 matches
Mail list logo
