> Thus spake Karsten M. Self (kmself@ix.netcom.com):
>
> > There are two aspect to dealing with spam. One is filtering the
> > messages. The other is reporting it.
>
> You can configure a threshold above which spamassassin will report spam
> as well. I'm not sure of the details, though.
>
Thus spake Karsten M. Self (kmself@ix.netcom.com):
> There are two aspect to dealing with spam. One is filtering the
> messages. The other is reporting it.
You can configure a threshold above which spamassassin will report spam
as well. I'm not sure of the details, though.
> My filters pro
> Thus spake Karsten M. Self ([EMAIL PROTECTED]):
>
> > There are two aspect to dealing with spam. One is filtering the
> > messages. The other is reporting it.
>
> You can configure a threshold above which spamassassin will report spam
> as well. I'm not sure of the details, though.
>
>
on Fri, Dec 21, 2001 at 10:15:14AM -0500, Justin R. Miller ([EMAIL PROTECTED])
wrote:
> Thus spake Karsten M. Self (kmself@ix.netcom.com):
>
> > I've got a few systems for trapping spam.
>
> I've been quite happy with spamassassin. Feel free to check out my
> writeup:
>
> http://codes
Thus spake Karsten M. Self ([EMAIL PROTECTED]):
> There are two aspect to dealing with spam. One is filtering the
> messages. The other is reporting it.
You can configure a threshold above which spamassassin will report spam
as well. I'm not sure of the details, though.
> My filters provi
on Fri, Dec 21, 2001 at 10:15:14AM -0500, Justin R. Miller ([EMAIL PROTECTED])
wrote:
> Thus spake Karsten M. Self ([EMAIL PROTECTED]):
>
> > I've got a few systems for trapping spam.
>
> I've been quite happy with spamassassin. Feel free to check out my
> writeup:
>
> http://codesor
>>Statements like this lead me to question whether you really know what
you're
>>talking about.
Nah, I never really claimed I knew what I was talking about. ;-)
Read back, I actually said that "I might be overstepping my knowledge..."
Just asking questions, trying to understand more about it.
I
> 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
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 you could si
I don't know this for certain, but I've got a feeling that it's this kind
of thing that would be very easy to implement in the Hurd - the microkernel
would make it very easy to start adding daemons that provide a layer between
requests for exec, forks etc and actually granting them.
Otoh, the hurd
Greetings,
I have experimented with creating an EXEC capability that is turned on by
default (as a quick hack). I didn't consider fork at the time since most
breeches involve execing a shell (or some other binary).
G'day,
sjames
Quoting Gary MacDougall <[EMAIL PROTECTED]>:
> Interesting.
>
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't gott
>>Statements like this lead me to question whether you really know what
you're
>>talking about.
Nah, I never really claimed I knew what I was talking about. ;-)
Read back, I actually said that "I might be overstepping my knowledge..."
Just asking questions, trying to understand more about it.
I
> 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
Take a look at the St. Jude kernel module/model paper on sourceforge. I
haven't gotten the module to do anything other than hang the box (under
2.4), but the paper itself is interesting, and along the lines of what
you want. Essentially, privileged processes have certain syscalls
watched (sys_exe
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 you could s
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
On Friday 21 December 2001 07:15, Justin R. Miller wrote:
> Thus spake Karsten M. Self (kmself@ix.netcom.com):
> > I've got a few systems for trapping spam.
>
> I've been quite happy with spamassassin. Feel free to check out my
> writeup:
>
> http://codesorcery.net/docs/spamtricks.html
I ju
I don't know this for certain, but I've got a feeling that it's this kind
of thing that would be very easy to implement in the Hurd - the microkernel
would make it very easy to start adding daemons that provide a layer between
requests for exec, forks etc and actually granting them.
Otoh, the hur
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
Interesting.
Has someone done some work on this?
I'm mean, lets face it, your running a bunch of
servers and they have boat loads of daemon's. Why
they'll need to fork/exec a shell is really a good
question -- in my mind, they don't. I could be wrong.
Why not simply build this ability into the
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 exec revokable syscalls, write a
syscall allowing a process to request revocation of unneeded syscalls, and
add that call to your daemon.
Kelly
> -Original Message-
> From: Ro
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
Greetings,
I have experimented with creating an EXEC capability that is turned on by default (as
a quick hack). I didn't consider fork at the time since most breeches involve execing
a shell (or some other binary).
G'day,
sjames
Quoting Gary MacDougall <[EMAIL PROTECTED]>:
> Interesting.
>
I should also add...
I do understand that running processes as "root" is
basically the problem... but in theory, the setup of running
things under a different user can be a pain -- why not
simply allow the kernel to handle it...
...
-Original Message-
From: Gary MacDougall [mailto:[EMAIL
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 off what was explained by Noah and Kelly,
it appears to me that Buffer Overru
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 gotten the module
Take a look at the St. Jude kernel module/model paper on sourceforge. I
haven't gotten the module to do anything other than hang the box (under
2.4), but the paper itself is interesting, and along the lines of what
you want. Essentially, privileged processes have certain syscalls
watched (sys_ex
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
On Friday 21 December 2001 07:15, Justin R. Miller wrote:
> Thus spake Karsten M. Self ([EMAIL PROTECTED]):
> > I've got a few systems for trapping spam.
>
> I've been quite happy with spamassassin. Feel free to check out my
> writeup:
>
> http://codesorcery.net/docs/spamtricks.html
I just
> 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
Interesting.
Has someone done some work on this?
I'm mean, lets face it, your running a bunch of
servers and they have boat loads of daemon's. Why
they'll need to fork/exec a shell is really a good
question -- in my mind, they don't. I could be wrong.
Why not simply build this ability into the
Thus spake Karsten M. Self (kmself@ix.netcom.com):
> I've got a few systems for trapping spam.
I've been quite happy with spamassassin. Feel free to check out my
writeup:
http://codesorcery.net/docs/spamtricks.html
--
Justin R. Miller <[EMAIL PROTECTED]>
View my website at http://c
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 exec revokable syscalls, write a
syscall allowing a process to request revocation of unneeded syscalls, and
add that call to your daemon.
Kelly
> -Original Message-
> From: R
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
Since we're on the 2.4 kernel, I have a question thats been
jawing at me and haven't really had the time to peel through
code and look...
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 ev
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
I should also add...
I do understand that running processes as "root" is
basically the problem... but in theory, the setup of running
things under a different user can be a pain -- why not
simply allow the kernel to handle it...
...
-Original Message-
From: Gary MacDougall [mailto:[EMAI
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 off what was explained by Noah and Kelly,
it appears to me that Buffer Overr
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
Hello,
Once upon a time I was necessary to execute some actions in response to
one program errors, which wrote their own messages in syslog. I has
written simplest script, which read syslogd's reporting from named pipe.
However, soon I has wanted to script reacted and on other messages in
sy
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
Thus spake Karsten M. Self ([EMAIL PROTECTED]):
> I've got a few systems for trapping spam.
I've been quite happy with spamassassin. Feel free to check out my
writeup:
http://codesorcery.net/docs/spamtricks.html
--
Justin R. Miller <[EMAIL PROTECTED]>
View my website at http://cod
Since we're on the 2.4 kernel, I have a question thats been
jawing at me and haven't really had the time to peel through
code and look...
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 e
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
Hello,
Once upon a time I was necessary to execute some actions in response to
one program errors, which wrote their own messages in syslog. I has
written simplest script, which read syslogd's reporting from named pipe.
However, soon I has wanted to script reacted and on other messages in
sys
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
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
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
stabl
on Fri, Dec 21, 2001 at 03:39:48AM -0500, k l u r t ([EMAIL PROTECTED]) wrote:
> On Friday 21 December 2001 02:16 am, [EMAIL PROTECTED] wrote:
> > Hey everyone,
> >
> > Ever wanted to party with your favorite porn stars??
>
> relay for spam
> geez.. what a waste of a good FreeBSD box..
I've
On Friday 21 December 2001 02:16 am, [EMAIL PROTECTED] wrote:
> Hey everyone,
>
> Ever wanted to party with your favorite porn stars??
relay for spam
geez.. what a waste of a good FreeBSD box..
@debian:~$ whois 64.38.226.213
CWIE LLC (NETBLK-CWIE-BLK-1)
1125 E Glendale AVE
Phoenix, A
on Fri, Dec 21, 2001 at 03:39:48AM -0500, k l u r t ([EMAIL PROTECTED]) wrote:
> On Friday 21 December 2001 02:16 am, [EMAIL PROTECTED] wrote:
> > Hey everyone,
> >
> > Ever wanted to party with your favorite porn stars??
>
> relay for spam
> geez.. what a waste of a good FreeBSD box..
I'v
Hey everyone,
Ever wanted to party with your favorite porn stars?? Well, now you can!! That's right. We at Ona zee pictures are constantly getting hundreds if not thousands of emails and phone calls from people asking how they can meet there favorite porn stars, so this is what we've decided to
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 such a secure kernel doesnt exist yet in the 2.4 line? Given
Debi
On Friday 21 December 2001 02:16 am, [EMAIL PROTECTED] wrote:
> Hey everyone,
>
> Ever wanted to party with your favorite porn stars??
relay for spam
geez.. what a waste of a good FreeBSD box..
@debian:~$ whois 64.38.226.213
CWIE LLC (NETBLK-CWIE-BLK-1)
1125 E Glendale AVE
Phoenix,
68 matches
Mail list logo
