Hi
I haven't read all the messages in this thread yet, but from
your first question about whether or not the kernel can detect
SIGSEGVs it seems you think that when a buffer is overrun, a
SIGSEGV is generated. This is not always the case.
i.e. If a buffer is overrun in a process, and there is ga
Hi
I haven't read all the messages in this thread yet, but from
your first question about whether or not the kernel can detect
SIGSEGVs it seems you think that when a buffer is overrun, a
SIGSEGV is generated. This is not always the case.
i.e. If a buffer is overrun in a process, and there is g
On Fri, Dec 28, 2001 at 11:18:35AM +0300, Nyarlathotep wrote:
> On Fri, 2001-12-28 at 03:22, Howland, Curtis wrote:
> > Naa, it's simian posturing. It happens with humans everywhere. I
> > enjoyed watching it in Good Will Hunting, and two days ago rented
> > Finding Forrester (same movie, differe
On Fri, Dec 28, 2001 at 11:18:35AM +0300, Nyarlathotep wrote:
> On Fri, 2001-12-28 at 03:22, Howland, Curtis wrote:
> > Naa, it's simian posturing. It happens with humans everywhere. I
> > enjoyed watching it in Good Will Hunting, and two days ago rented
> > Finding Forrester (same movie, differ
On Fri, 2001-12-28 at 03:22, Howland, Curtis wrote:
> Naa, it's simian posturing. It happens with humans everywhere. I
> enjoyed watching it in Good Will Hunting, and two days ago rented
> Finding Forrester (same movie, different actors), and sure enough
> lots of simian posturing. "You dare to
On Fri, 2001-12-28 at 03:22, Howland, Curtis wrote:
> Naa, it's simian posturing. It happens with humans everywhere. I
> enjoyed watching it in Good Will Hunting, and two days ago rented
> Finding Forrester (same movie, different actors), and sure enough
> lots of simian posturing. "You dare t
> -Original Message-
> From: Gary MacDougall
>
> I'm gong to get flamed like hell for this, but I think the general
> attitude of people that consider themselves "Linux Security
> Guru's" sucks!
> If you've ever visited #linux on IRC or talked with people in
> a chat room
> about Linux
> -Original Message-
> From: Gary MacDougall
>
> I'm gong to get flamed like hell for this, but I think the general
> attitude of people that consider themselves "Linux Security
> Guru's" sucks!
> If you've ever visited #linux on IRC or talked with people in
> a chat room
> about Linux
> Now, I do not know about American law, but at least in Finland the
>guy whose gun (assault rifles are illegal anyway unless they are
>rendered non-automatic) was stolen, is likely to get punished as well!
>It depends on how the gun was stored: it needs to be locked away in a
>different location
> Now, I do not know about American law, but at least in Finland the
>guy whose gun (assault rifles are illegal anyway unless they are
>rendered non-automatic) was stolen, is likely to get punished as well!
>It depends on how the gun was stored: it needs to be locked away in a
>different locatio
> Just because people are "dumb" or not as fortunate as other more
> "privy" people, doesn't mean that the law should bypass the
> "unfortunate". The law (at least in the US) were specifically
> created to protect people in such circumstances. Why should
> computer law be any different?
Actual
> Just because people are "dumb" or not as fortunate as other more
> "privy" people, doesn't mean that the law should bypass the
> "unfortunate". The law (at least in the US) were specifically
> created to protect people in such circumstances. Why should
> computer law be any different?
Actua
* Alvin Oga
| On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
|
| > > making the disks readonly is not trivial ...
| > > lots of work to make it readonly.. a fun project ...
| >
| > Not really. Nothing should write anywhere except /var and /tmp
| > (did I miss any). Also, if you have users, th
* Alvin Oga
| On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
|
| > > making the disks readonly is not trivial ...
| > > lots of work to make it readonly.. a fun project ...
| >
| > Not really. Nothing should write anywhere except /var and /tmp
| > (did I miss any). Also, if you have users, t
On Tuesday, December 25, 2001, at 08:34 , Alvin Oga wrote:
On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
making the disks readonly is not trivial ...
lots of work to make it readonly.. a fun project ...
Not really. Nothing should write anywhere except /var and /tmp
(did I miss any). Als
On Tuesday, December 25, 2001, at 08:34 , Alvin Oga wrote:
>
>
> On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
>
>>> making the disks readonly is not trivial ...
>>> lots of work to make it readonly.. a fun project ...
>>
>> Not really. Nothing should write anywhere except /var and /tmp
>> (di
Hi,
Gary MacDougall wrote:
>
> Actually your point of view basically states that its "ok" for anyone to
> tresspass.
no, i just said, that laws can´t help against unknown people.
until now nobody broke in my house, and i think because of two facts:
- i always keep my doors and windows closed (w
Hi,
Gary MacDougall wrote:
>
> Actually your point of view basically states that its "ok" for anyone to
> tresspass.
no, i just said, that laws can´t help against unknown people.
until now nobody broke in my house, and i think because of two facts:
- i always keep my doors and windows closed (
l Message-
> From: Gary MacDougall [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 26, 2001 11:47
> To: Howland, Curtis; Ralf Dreibrodt
> Cc: debian-security@lists.debian.org
> Subject: Re: Secure 2.4.x kernel
>
>
> Actually your point of view basically states tha
ter
law be any different?
I see you point, do you see mine?
g.
- Original Message -
From: "Howland, Curtis" <[EMAIL PROTECTED]>
To: "Ralf Dreibrodt" <[EMAIL PROTECTED]>; "Gary MacDougall"
<[EMAIL PROTECTED]>
Cc:
Sent: Tuesday, Decembe
hi ya
for a simple 5 minute kernel patch...
http://www.Linux-Sec.net/Harden/kernel.gwif.html
- apply openwall if you are using 2.2.x kernels
- ruh libsafe if you wanna try a prevent some buffer overflows
- if you wanna get into all the fun stuff... lots of other
On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
> > making the disks readonly is not trivial ...
> > lots of work to make it readonly.. a fun project ...
>
> Not really. Nothing should write anywhere except /var and /tmp
> (did I miss any). Also, if you have users, then /home.
/etc is written
l Message-
> From: Gary MacDougall [mailto:[EMAIL PROTECTED]]
> Sent: Wednesday, December 26, 2001 11:47
> To: Howland, Curtis; Ralf Dreibrodt
> Cc: [EMAIL PROTECTED]
> Subject: Re: Secure 2.4.x kernel
>
>
> Actually your point of view basically states that its "ok
omputer
law be any different?
I see you point, do you see mine?
g.
- Original Message -
From: "Howland, Curtis" <[EMAIL PROTECTED]>
To: "Ralf Dreibrodt" <[EMAIL PROTECTED]>; "Gary MacDougall"
<[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]&
and
deliberately turned on is the first step.
Curt-
> -Original Message-
> From: Ralf Dreibrodt [mailto:[EMAIL PROTECTED]
> Sent: Tuesday, December 25, 2001 23:07
> To: Gary MacDougall
> Cc: debian-security@lists.debian.org
> Subject: Re: Secure 2.4.x kernel
>
>
&
hi ya
for a simple 5 minute kernel patch...
http://www.Linux-Sec.net/Harden/kernel.gwif.html
- apply openwall if you are using 2.2.x kernels
- ruh libsafe if you wanna try a prevent some buffer overflows
- if you wanna get into all the fun stuff... lots of other
On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
> > making the disks readonly is not trivial ...
> > lots of work to make it readonly.. a fun project ...
>
> Not really. Nothing should write anywhere except /var and /tmp
> (did I miss any). Also, if you have users, then /home.
/etc is writte
and
deliberately turned on is the first step.
Curt-
> -Original Message-
> From: Ralf Dreibrodt [mailto:[EMAIL PROTECTED]]
> Sent: Tuesday, December 25, 2001 23:07
> To: Gary MacDougall
> Cc: [EMAIL PROTECTED]
> Subject: Re: Secure 2.4.x kernel
>
>
> Hi
It doesn't need to spawn a new shell to allow root access. It
can just load the a properly-linked shell into memory (not
calling execve), then jump to main.
Or it can not use a shell at all. Shells aren't special in any way.
True, shells aren't special. But if someone tries to smash the stack,
>> It doesn't need to spawn a new shell to allow root access. It
>> can just load the a properly-linked shell into memory (not
>> calling execve), then jump to main.
>>
>> Or it can not use a shell at all. Shells aren't special in any way.
>
> True, shells aren't special. But if someone tries to
Hi,
Gary MacDougall wrote:
>
> Hmmm... Mom has a good point.
>
> I think the bottom line is that we'll never have 100% security until
> there are laws that protect the break-in's and hacking that occurs.
> Still laws... not crappy little wrist slapping type laws.
laws can´t do anything against
> On Monday, December 24, 2001, at 10:52 , Gary MacDougall wrote:
>
> > Someone said that St. Jude was what I was looking for, and I think
> > its pretty much *exactly* what I was pointing out.
>
> Can't, in general, stop an attack. All the attacker has to do is
> not do unusual calls which jude mo
Hi,
Gary MacDougall wrote:
>
> Hmmm... Mom has a good point.
>
> I think the bottom line is that we'll never have 100% security until
> there are laws that protect the break-in's and hacking that occurs.
> Still laws... not crappy little wrist slapping type laws.
laws can´t do anything against
> On Monday, December 24, 2001, at 10:52 , Gary MacDougall wrote:
>
> > Someone said that St. Jude was what I was looking for, and I think
> > its pretty much *exactly* what I was pointing out.
>
> Can't, in general, stop an attack. All the attacker has to do is
> not do unusual calls which jude m
On Monday, December 24, 2001, at 10:52 , Gary MacDougall wrote:
Someone said that St. Jude was what I was looking for, and I think
its pretty much *exactly* what I was pointing out.
Can't, in general, stop an attack. All the attacker has to do is
not do unusual calls which jude monitors, whi
> On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
>
> > Wouldn't it be nice to be able to run the kernel in "secure mode"?
> > I'm curious to know if we could limit the amount of "root exploits"
> > by this method, it would REALLY harden up security on a
> > Linux box... anyone hav
making the disks readonly is not trivial ...
lots of work to make it readonly.. a fun project ...
Not really. Nothing should write anywhere except /var and /tmp
(did I miss any). Also, if you have users, then /home.
In particular, if it is in $PATH, make it read-only. Many root
kits trojan
On Monday, December 24, 2001, at 10:52 , Gary MacDougall wrote:
> Someone said that St. Jude was what I was looking for, and I think
> its pretty much *exactly* what I was pointing out.
Can't, in general, stop an attack. All the attacker has to do is
not do unusual calls which jude monitors, w
> On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
>
> > Wouldn't it be nice to be able to run the kernel in "secure mode"?
> > I'm curious to know if we could limit the amount of "root exploits"
> > by this method, it would REALLY harden up security on a
> > Linux box... anyone ha
> making the disks readonly is not trivial ...
> lots of work to make it readonly.. a fun project ...
Not really. Nothing should write anywhere except /var and /tmp
(did I miss any). Also, if you have users, then /home.
In particular, if it is in $PATH, make it read-only. Many root
kits troja
hi ya
> Also, when you look at how memory is laid out, having two stacks
> is problematic. Under linux, it looks like this:
>
> ---
>| KERNEL | | stack | < grows downward
>||---
>||
>| user | > ---
>|
hi ya
On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
>
> On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
>
> > Wouldn't it be nice to be able to run the kernel in "secure mode"?
> > I'm curious to know if we could limit the amount of "root exploits"
> > by this method, it wou
hi ya
> Also, when you look at how memory is laid out, having two stacks
> is problematic. Under linux, it looks like this:
>
> ---
>| KERNEL | | stack | < grows downward
>||---
>||
>| user | > ---
>
hi ya
On Mon, 24 Dec 2001, Anthony DeRobertis wrote:
>
> On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
>
> > Wouldn't it be nice to be able to run the kernel in "secure mode"?
> > I'm curious to know if we could limit the amount of "root exploits"
> > by this method, it wo
On Saturday, December 22, 2001, at 07:22 , System Administrator wrote:
The assembly statement "jsr" (jump to subroutine) puts the
return address
on the same stack, where space for local variables is reserved.
Local variables, parameters, temporaries, etc. Yes, it's all the
same stack on ev
On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
Wouldn't it be nice to be able to run the kernel in "secure mode"?
I'm curious to know if we could limit the amount of "root exploits"
by this method, it would REALLY harden up security on a
Linux box... anyone have any opinions on
On Saturday, December 22, 2001, at 07:22 , System Administrator wrote:
> The assembly statement "jsr" (jump to subroutine) puts the
> return address
> on the same stack, where space for local variables is reserved.
>
Local variables, parameters, temporaries, etc. Yes, it's all the
same stack
On Friday, December 21, 2001, at 03:25 , Gary MacDougall wrote:
> Wouldn't it be nice to be able to run the kernel in "secure mode"?
> I'm curious to know if we could limit the amount of "root exploits"
> by this method, it would REALLY harden up security on a
> Linux box... anyone have any opin
On Fri, Dec 21, 2001 at 03:25:04PM -0500, Gary MacDougall wrote:
> Hmmm I don't buy that this *couldn't* be done on the Intel.
> I might be overstepping my knowledge, but I'm sure there
> *must* be a way.
The first method that comes to mind is making the stack segment
non-executable. IIRC, this i
On Fri, Dec 21, 2001 at 03:25:04PM -0500, Gary MacDougall wrote:
> Hmmm I don't buy that this *couldn't* be done on the Intel.
> I might be overstepping my knowledge, but I'm sure there
> *must* be a way.
The first method that comes to mind is making the stack segment
non-executable. IIRC, this
Well hello list,
it could be, that i'm overstepping my knowledge (and my english).
If i have well understood, one of the problems of bufferoverruns is
the follwing:
The assembly statement "jsr" (jump to subroutine) puts the return address
on the same stack, where space for local variables is
Well hello list,
it could be, that i'm overstepping my knowledge (and my english).
If i have well understood, one of the problems of bufferoverruns is
the follwing:
The assembly statement "jsr" (jump to subroutine) puts the return address
on the same stack, where space for local variables is
x27;Gary MacDougall'; debian-security@lists.debian.org
Subject: RE: Secure 2.4.x kernel
> Hmmm I don't buy that this *couldn't* be done on the Intel.
> I might be overstepping my knowledge, but I'm sure there
> *must* be a way.
> Going back to my 68k days, it would
> Hmmm I don't buy that this *couldn't* be done on the Intel.
> I might be overstepping my knowledge, but I'm sure there
> *must* be a way.
> Going back to my 68k days, it would have been fairly easy
> to write this. Hey, I'm not an Intel assembly/opcode expert,
> but it seems to me, I think that
d if you do that,
well, I think the amount of vulnerability goes way down.
Gary
-Original Message-
From: Matthew Sackman [mailto:[EMAIL PROTECTED]
Sent: Friday, December 21, 2001 3:01 PM
To: debian-security@lists.debian.org
Subject: Re: Secure 2.4.x kernel
I don't know this for certain
TECTED]
> > Sent: Friday, December 21, 2001 11:17 AM
> > To: debian-security@lists.debian.org
> > Subject:RE: Secure 2.4.x kernel
> >
> > And how would one do that?
> >
> > >>> Kelly Martin <[EMAIL PROTECTED]> 12/21/01 12:09PM &
be wrong.
>
> Why not simply build this ability into the kernel?
> Could be an option at menuconfig time...
>
> Gary
>
> -Original Message-
> From: Kelly Martin [mailto:[EMAIL PROTECTED]
> Sent: Friday, December 21, 2001 12:24 PM
> To: 'Robert Clay&#x
very interesting. thanks.
-Original Message-
From: Andres Salomon [mailto:[EMAIL PROTECTED]
Sent: Friday, December 21, 2001 1:33 PM
To: debian-security@lists.debian.org
Subject: Re: Secure 2.4.x kernel
Take a look at the St. Jude kernel module/model paper on sourceforge. I
haven&#
27;Gary MacDougall'; [EMAIL PROTECTED]
Subject: RE: Secure 2.4.x kernel
> Hmmm I don't buy that this *couldn't* be done on the Intel.
> I might be overstepping my knowledge, but I'm sure there
> *must* be a way.
> Going back to my 68k days, it would have been fair
> Hmmm I don't buy that this *couldn't* be done on the Intel.
> I might be overstepping my knowledge, but I'm sure there
> *must* be a way.
> Going back to my 68k days, it would have been fairly easy
> to write this. Hey, I'm not an Intel assembly/opcode expert,
> but it seems to me, I think that
[mailto:[EMAIL PROTECTED]
> Sent: Friday, December 21, 2001 12:24 PM
> To: 'Robert Clay'; debian-security@lists.debian.org
> Subject: RE: Secure 2.4.x kernel
>
>
> As far as I know, Linux does not support doing that. So the way you do it
> is modify your kernel to
d if you do that,
well, I think the amount of vulnerability goes way down.
Gary
-Original Message-
From: Matthew Sackman [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 21, 2001 3:01 PM
To: [EMAIL PROTECTED]
Subject: Re: Secure 2.4.x kernel
I don't know this for certain, but I'v
Hi,
Quoting Alson van der Meulen ([EMAIL PROTECTED]):
> http://www.openwall.com/linux/
> The Openwall patches protect against explointing buffer overruns I
> think, they're not available for 2.4 yet though.
You might seem family, but you should still learn to quote :) (and follow
the nettiquette
ROTECTED]]
> > Sent: Friday, December 21, 2001 11:17 AM
> > To: [EMAIL PROTECTED]
> > Subject:RE: Secure 2.4.x kernel
> >
> > And how would one do that?
> >
> > >>> Kelly Martin <[EMAIL PROTECTED]> 12/21/01 12:09PM >>
Jor-el wrote:
> I'm looking to put a 2.4 kernel with (preferably one of the more
> recent ones with the new VM subsytem) on a firewall and secure a lab that
> I administer. Which kernel version is best suited to this?
I set up a Debian based firewall and used kernel 2.4.16. It's running
wi
his ability into the kernel?
Could be an option at menuconfig time...
Gary
-Original Message-
From: Kelly Martin [mailto:[EMAIL PROTECTED]
Sent: Friday, December 21, 2001 12:24 PM
To: 'Robert Clay'; debian-security@lists.debian.org
Subject: RE: Secure 2.4.x kernel
As far as
; From: Robert Clay [SMTP:[EMAIL PROTECTED]
> Sent: Friday, December 21, 2001 11:17 AM
> To: debian-security@lists.debian.org
> Subject: RE: Secure 2.4.x kernel
>
> And how would one do that?
>
> >>> Kelly Martin <[EMAIL PROTECTED]> 12/21/01 12:09PM >&
And how would one do that?
>>> Kelly Martin <[EMAIL PROTECTED]> 12/21/01 12:09PM >>>
...Taking away the fork and exec syscalls from a daemon which does not
need to do either would be a good start.
> Now heres my next questions and its a security one.
> Based off what was explained by Noah and Kelly,
> it appears to me that Buffer Overruns can be dealt
> with at the kernel level and that there is probably
> a way in the kernel to stop a root exploit during
> a buffer overrun. Why hasn't (or
Gary MacDougall([EMAIL PROTECTED])@2001.12.21 11:59:36 +:
> Thanks everyone for the answer.
>
> I was pretty sure that the kernel would be able
> to detect the fault, but I needed to *make* sure
> before i asked another question.
>
> Now heres my next questions and its a security one.
> Based
be wrong.
>
> Why not simply build this ability into the kernel?
> Could be an option at menuconfig time...
>
> Gary
>
> -Original Message-
> From: Kelly Martin [mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 21, 2001 12:24 PM
> To: 'Robert Clay
ll [mailto:[EMAIL PROTECTED]
Sent: Friday, December 21, 2001 12:00 PM
To: Kelly Martin; 'Noah L. Meyerhans'; debian-security@lists.debian.org
Subject: RE: Secure 2.4.x kernel
Thanks everyone for the answer.
I was pretty sure that the kernel would be able
to detect the fault, but I needed to
[EMAIL PROTECTED]
Sent: Friday, December 21, 2001 11:00 AM
To: 'Noah L. Meyerhans'; debian-security@lists.debian.org
Subject: RE: Secure 2.4.x kernel
> So, in short, seg faults *come*from* the kernel, so of course the kernel
> knows when a program segfaults.
Actually, seg
very interesting. thanks.
-Original Message-
From: Andres Salomon [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 21, 2001 1:33 PM
To: [EMAIL PROTECTED]
Subject: Re: Secure 2.4.x kernel
Take a look at the St. Jude kernel module/model paper on sourceforge. I
haven't gotte
[mailto:[EMAIL PROTECTED]]
> Sent: Friday, December 21, 2001 12:24 PM
> To: 'Robert Clay'; [EMAIL PROTECTED]
> Subject: RE: Secure 2.4.x kernel
>
>
> As far as I know, Linux does not support doing that. So the way you do it
> is modify your kernel to make fork and e
Hi,
Quoting Alson van der Meulen ([EMAIL PROTECTED]):
> http://www.openwall.com/linux/
> The Openwall patches protect against explointing buffer overruns I
> think, they're not available for 2.4 yet though.
You might seem family, but you should still learn to quote :) (and follow
the nettiquette
> So, in short, seg faults *come*from* the kernel, so of course the kernel
> knows when a program segfaults.
Actually, segmentation faults come from the processor (more specifically,
the memory management unit). The kernel processes the hardware exception
and converts it into a signal to be sent
On Fri, Dec 21, 2001 at 10:17:35AM -0500, Gary MacDougall wrote:
> In the kernel (ok, stand up you kernel guru's!), when a
> "segmentation fault" is raised, I don't care where, doesn't the
> kernel get some sort of notification event?
Of course the kernel knows. The kernel is why seg faults can
Jor-el wrote:
> I'm looking to put a 2.4 kernel with (preferably one of the more
> recent ones with the new VM subsytem) on a firewall and secure a lab that
> I administer. Which kernel version is best suited to this?
I set up a Debian based firewall and used kernel 2.4.16. It's running
w
ld this ability into the kernel?
Could be an option at menuconfig time...
Gary
-Original Message-
From: Kelly Martin [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 21, 2001 12:24 PM
To: 'Robert Clay'; [EMAIL PROTECTED]
Subject: RE: Secure 2.4.x kernel
As far as I know, Linux do
; From: Robert Clay [SMTP:[EMAIL PROTECTED]]
> Sent: Friday, December 21, 2001 11:17 AM
> To: [EMAIL PROTECTED]
> Subject: RE: Secure 2.4.x kernel
>
> And how would one do that?
>
> >>> Kelly Martin <[EMAIL PROTECTED]> 12/21/01 12:09PM >>>
> .
And how would one do that?
>>> Kelly Martin <[EMAIL PROTECTED]> 12/21/01 12:09PM >>>
...Taking away the fork and exec syscalls from a daemon which does not
need to do either would be a good start.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact
- Original Message -
From: "Phillip Hofmeister" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc:
Sent: Friday, December 21, 2001 8:28 AM
Subject: Re: Secure 2.4.x kernel
>
>
> Or is it the
> > case that such a secure kernel doesnt exist yet in the
On Fri, Dec 21, 2001 at 08:52:56 -0600, Jor-el wrote:
> One of the puzzling things mentioned on that site (as well as the Openwall
> site that it linked to) was 'trampolines'. Any idea what these are?
I guess it's the same trampolines mentioned in gcc's documentation:
: GCC implements taking th
> Now heres my next questions and its a security one.
> Based off what was explained by Noah and Kelly,
> it appears to me that Buffer Overruns can be dealt
> with at the kernel level and that there is probably
> a way in the kernel to stop a root exploit during
> a buffer overrun. Why hasn't (or
On Fri, 21 Dec 2001, marcin wrote:
> On Fri, Dec 21, 2001 at 12:14:33AM -0600, Jor-el wrote:
>
> www.grsecurity.net
>
> Where is all :>
>
Marcin,
Thanks for the pointer. I will look at those patches. One of the
puzzling things mentioned on that site (as well as the Openwall site that
i
Gary MacDougall([EMAIL PROTECTED])@2001.12.21 11:59:36 +:
> Thanks everyone for the answer.
>
> I was pretty sure that the kernel would be able
> to detect the fault, but I needed to *make* sure
> before i asked another question.
>
> Now heres my next questions and its a security one.
> Base
ll [mailto:[EMAIL PROTECTED]]
Sent: Friday, December 21, 2001 12:00 PM
To: Kelly Martin; 'Noah L. Meyerhans'; [EMAIL PROTECTED]
Subject: RE: Secure 2.4.x kernel
Thanks everyone for the answer.
I was pretty sure that the kernel would be able
to detect the fault, but I needed to *make* sure
be
mailto:[EMAIL PROTECTED]]
Sent: Friday, December 21, 2001 11:00 AM
To: 'Noah L. Meyerhans'; [EMAIL PROTECTED]
Subject: RE: Secure 2.4.x kernel
> So, in short, seg faults *come*from* the kernel, so of course the kernel
> knows when a program segfaults.
Actually, segmentation faults c
On Fri, 21 Dec 2001, Moritz Schulte wrote:
> Phillip Hofmeister <[EMAIL PROTECTED]> writes:
>
> > Unless you like recompiling your kernel 2 or 3 times a month I
> > wouldn't look to 2.4 for a FIREWALL kernel yet. If you want the
> > neat features of 2.4 I would recomend installing 2.2 on the fir
On Fri, Dec 21, 2001 at 12:14:33AM -0600, Jor-el wrote:
> Hi,
>
> I'm looking to put a 2.4 kernel with (preferably one of the more
> recent ones with the new VM subsytem) on a firewall and secure a lab that
> I administer. Which kernel version is best suited to this? Or is it the
> case that
Phillip Hofmeister <[EMAIL PROTECTED]> writes:
> Unless you like recompiling your kernel 2 or 3 times a month I
> wouldn't look to 2.4 for a FIREWALL kernel yet. If you want the
> neat features of 2.4 I would recomend installing 2.2 on the firewall
> and another box on the internal network with 2
> So, in short, seg faults *come*from* the kernel, so of course the kernel
> knows when a program segfaults.
Actually, segmentation faults come from the processor (more specifically,
the memory management unit). The kernel processes the hardware exception
and converts it into a signal to be sent
On Fri, Dec 21, 2001 at 10:17:35AM -0500, Gary MacDougall wrote:
> In the kernel (ok, stand up you kernel guru's!), when a
> "segmentation fault" is raised, I don't care where, doesn't the
> kernel get some sort of notification event?
Of course the kernel knows. The kernel is why seg faults can
Or is it the
> case that such a secure kernel doesnt exist yet in the
2.4 line? Given
> Debian's tradition of backporting security fixes, perhaps
there is a
> Debian-ized 2.4 kernel that would be suited to what I
have in mind?
I run 2.2.18pre21 on my firewall. It has been known to be
stable
w?
Gary
- Original Message -
From: "Phillip Hofmeister" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Friday, December 21, 2001 8:28 AM
Subject: Re: Secure 2.4.x kernel
>
>
> Or is it the
> > case that such a secure ker
On Fri, Dec 21, 2001 at 08:52:56 -0600, Jor-el wrote:
> One of the puzzling things mentioned on that site (as well as the Openwall
> site that it linked to) was 'trampolines'. Any idea what these are?
I guess it's the same trampolines mentioned in gcc's documentation:
: GCC implements taking t
On Fri, 21 Dec 2001, marcin wrote:
> On Fri, Dec 21, 2001 at 12:14:33AM -0600, Jor-el wrote:
>
> www.grsecurity.net
>
> Where is all :>
>
Marcin,
Thanks for the pointer. I will look at those patches. One of the
puzzling things mentioned on that site (as well as the Openwall site that
On Fri, 21 Dec 2001, Moritz Schulte wrote:
> Phillip Hofmeister <[EMAIL PROTECTED]> writes:
>
> > Unless you like recompiling your kernel 2 or 3 times a month I
> > wouldn't look to 2.4 for a FIREWALL kernel yet. If you want the
> > neat features of 2.4 I would recomend installing 2.2 on the fi
On Fri, Dec 21, 2001 at 12:14:33AM -0600, Jor-el wrote:
> Hi,
>
> I'm looking to put a 2.4 kernel with (preferably one of the more
> recent ones with the new VM subsytem) on a firewall and secure a lab that
> I administer. Which kernel version is best suited to this? Or is it the
> case tha
1 - 100 of 104 matches
Mail list logo
