From owner-kernel-audit@nl.linux.org Mon Aug  7 01:17:45 2000
Received: by humbolt.nl.linux.org id <S92183AbQHFXQU>;
	Mon, 7 Aug 2000 01:16:20 +0200
Received: from modem-52.crixivan.dialup.pol.co.uk ([62.136.87.52]:38149 "EHLO
        braecklein.freeserve.co.uk") by humbolt.nl.linux.org with ESMTP
	id <S92173AbQHFXPp>; Mon, 7 Aug 2000 01:15:45 +0200
Received: (from live@localhost)
	by braecklein.freeserve.co.uk (8.10.2/8.9.1) id e76NERt08466
	for kernel-audit@mail.nl.linux.org; Mon, 7 Aug 2000 00:14:27 +0100
Date:   Mon, 7 Aug 2000 00:14:27 +0100
From:   Natasha Live <live@braecklein.freeserve.co.uk>
To:     kernel <kernel-audit@nl.linux.org>
Subject: TEST
Message-ID: <20000807001427.D7983@braecklein.freeserve.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

As I don't seem to be getting anymail from this list, i'm
just checking to see if it is still alive.

------
- Live
------

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 02:12:50 2000
Received: by humbolt.nl.linux.org id <S92191AbQHGALW>;
	Mon, 7 Aug 2000 02:11:22 +0200
Received: from user49-90.jakinternet.co.uk ([212.41.49.90]:4613 "EHLO
        linux.home") by humbolt.nl.linux.org with ESMTP id <S92173AbQHGAKx>;
	Mon, 7 Aug 2000 02:10:53 +0200
Received: from localhost (mistral@localhost)
	by linux.home (8.9.3/8.9.3) with ESMTP id BAA08023;
	Mon, 7 Aug 2000 01:15:38 GMT
Date:   Mon, 7 Aug 2000 01:15:38 +0000 (GMT)
From:   James Stevenson <mistral@stevenson.zetnet.co.uk>
To:     Natasha Live <live@braecklein.freeserve.co.uk>
cc:     kernel <kernel-audit@nl.linux.org>
Subject: Re: TEST
In-Reply-To: <20000807001427.D7983@braecklein.freeserve.co.uk>
Message-ID: <Pine.LNX.4.21.0008070115150.8021-100000@linux.home>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


Hi

yep you are on this list
i dont get any mail on it either :P

cya
	James

On Mon, 7 Aug 2000, Natasha Live wrote:

> As I don't seem to be getting anymail from this list, i'm
> just checking to see if it is still alive.
> 
> ------
> - Live
> ------
> 
> Kernel-audit:  discussion list for security and the linux kernel
> Archive:       http://mail.nl.linux.org/kernel-audit/
> 

-- 
---------------------------------------------
Check Out: http://www.users.zetnet.co.uk/james/
E-Mail: mistral@stevenson.zetnet.co.uk
  1:10am  up  8:46,  7 users,  load average: 0.46, 0.56, 0.49


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 08:42:10 2000
Received: by humbolt.nl.linux.org id <S92173AbQHGGkk>;
	Mon, 7 Aug 2000 08:40:40 +0200
Received: from cs16265-63.austin.rr.com ([24.162.65.63]:42990 "EHLO
        server.fdragon.lan") by humbolt.nl.linux.org with ESMTP
	id <S92166AbQHGGkM>; Mon, 7 Aug 2000 08:40:12 +0200
Received: from fdragon by server.fdragon.lan with local (Exim 3.12 #1 (Debian))
	id 13LgZx-00023C-00; Mon, 07 Aug 2000 01:40:05 -0500
Date:   Mon, 7 Aug 2000 01:40:04 -0500
From:   Fire Dragon <fdragon@io.com>
To:     James Stevenson <mistral@stevenson.zetnet.co.uk>
Cc:     kernel-audit@nl.linux.org
Subject: Re: TEST
Message-ID: <20000807014004.A7264@fdragon.lan>
References: <20000807001427.D7983@braecklein.freeserve.co.uk> <Pine.LNX.4.21.0008070115150.8021-100000@linux.home>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="PNTmBPCT7hxwcZjr"
User-Agent: Mutt/1.0.1i
In-Reply-To: <Pine.LNX.4.21.0008070115150.8021-100000@linux.home>; from mistral@stevenson.zetnet.co.uk on Mon, Aug 07, 2000 at 01:15:38AM +0000
Organization: Hail Eris! Fnord!
X-URL:  http://www.io.com/~fdragon/
X-Sysadmin: BOFH
X-Operating-System: Linux 2.2.17-idepci i686
X-No-Archive: Yes
X-Copyright: This message may not be reproduced, in whole or in part, for any purpose without writen prior permission. Prior permission for BUGTRAQ is implicit.
X-UCE-Policy: By US Code Title 47, Sec.227(a)(2)(B), a computer/modem/printer meets the definition of a telephone fax machine. By US Code Title 47, Sec.227(b)(1)(C), it is unlawful to send any unsolicited advertisement to such equipment. By US Code Title 47, Sec.227(b)(3)(C), a violation of the aforementioned Section is punishable by action to recover actual monetary loss, or 500 dollars, whichever is greater, for each violation.
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


--PNTmBPCT7hxwcZjr
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

On Mon, Aug 07, 2000 at 01:15:38AM +0000, James Stevenson wrote:
> yep you are on this list i dont get any mail on it either :P

Wow... there be traffic here.

Either way. I'm going to add some topic to this.

OpenBSD seems to have something up on linux now in the way of security. A
feature I rather like and am almost tempted to learn enough kernel hacking
to port myself. The feature I'm speaking of happens to be encrypted swap.

I know the current kernel is incapable of handling encryption (yes I know
about kerneli.org and the patches there...) but I'm kind of wondering how
much trouble it would be to actually add such a feature.

Then again without encrypted file systems this is a bit pointless...

ttylz

--=20
AIM: FDragon666			ICQ: 9333698
URL: http://www.io.com/~fdragon	IRC: fdragon

Today is Prickle-Prickle, day 73 in the season of Confusion, 3166.

Tip of the Day:
	Never fry bacon in the nude.

	[Correction: always fry bacon in the nude; you'll learn not to burn it]

--PNTmBPCT7hxwcZjr
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5jlnED7SLVY5gOpoRAbT6AKCDP1k2NIEmOyxi4+GQjPiiS9okOwCff29E
jLB1Wg7TzYvE5Uee1QzFexk=
=k8yS
-----END PGP SIGNATURE-----

--PNTmBPCT7hxwcZjr--

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 09:22:41 2000
Received: by humbolt.nl.linux.org id <S92166AbQHGHVR>;
	Mon, 7 Aug 2000 09:21:17 +0200
Received: from mailrelay.wirehub.nl ([195.86.25.80]:20494 "EHLO
        mailrelay.wirehub.nl") by humbolt.nl.linux.org with ESMTP
	id <S92181AbQHGHUn>; Mon, 7 Aug 2000 09:20:43 +0200
Received: from poindexter.wirehub.nl (poindexter.wirehub.nl [194.165.93.194])
	by mailrelay.wirehub.nl (8.9.3/8.9.3) with ESMTP id JAA12092
	for <kernel-audit@nl.linux.org>; Mon, 7 Aug 2000 09:20:43 +0200 (CEST)
Date:   Mon, 7 Aug 2000 09:20:42 +0200 (CEST)
From:   "L. Besselink" <leen@poindexter.wirehub.nl>
To:     kernel-audit@nl.linux.org
Subject: Re: TEST
In-Reply-To: <20000807014004.A7264@fdragon.lan>
Message-ID: <Pine.BSF.4.21.0008070912390.31053-100000@poindexter.wirehub.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, Fire Dragon wrote:

> On Mon, Aug 07, 2000 at 01:15:38AM +0000, James Stevenson wrote:
> 
> I know the current kernel is incapable of handling encryption (yes I know
> about kerneli.org and the patches there...) but I'm kind of wondering how
> much trouble it would be to actually add such a feature.

have no idea, but if you can encrypt filesystems, why then not a swapfile
(yes file), improving on swapfile performance would be greatly
appreciapted by people anyway. You could also look into creating an
encrypted swap as you are doing now, by patching your kernel first with
kerneli.org patches.

> Then again without encrypted file systems this is a bit pointless...
> 

Those are at kerneli.org, but don't expect them to be added to the
mainstream kernels just yet. Apart from coding style and so on (which
could be a reason), Linus won't let it happen just yet, but eventually it
will, so just go help them and it will be in the mainstream kernels soon
enough.

> ttylz

Hope this helps,
	Lennie.


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 15:06:19 2000
Received: by humbolt.nl.linux.org id <S92195AbQHGNFD>;
	Mon, 7 Aug 2000 15:05:03 +0200
Received: from ppp104-yorkpa.netrax.net ([205.231.165.104]:16134 "EHLO
        yinyang.hjsoft.com") by humbolt.nl.linux.org with ESMTP
	id <S92180AbQHGNEb>; Mon, 7 Aug 2000 15:04:31 +0200
Received: from localhost (god@localhost)
	by yinyang.hjsoft.com (8.11.0.Beta1/8.10.1) with ESMTP id e77DF1207113
	for <kernel-audit@nl.linux.org>; Mon, 7 Aug 2000 09:15:07 -0400
Date:   Mon, 7 Aug 2000 09:15:01 -0400 (EDT)
From:   "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>
Reply-To: god@yinyang.hjsoft.com
To:     kernel-audit@nl.linux.org
Subject: encrypting swap (was Re: TEST)
In-Reply-To: <Pine.BSF.4.21.0008070912390.31053-100000@poindexter.wirehub.nl>
Message-ID: <Pine.LNX.4.21.0008070905570.7070-100000@yinyang.hjsoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, L. Besselink wrote:

> On Mon, 7 Aug 2000, Fire Dragon wrote:
> 
> have no idea, but if you can encrypt filesystems, why then not a swapfile
> (yes file), improving on swapfile performance would be greatly
> appreciapted by people anyway. You could also look into creating an
> encrypted swap as you are doing now, by patching your kernel first with
> kerneli.org patches.
>
These patches use the loopback feature, so if your swap partition is
/dev/hda2. The you setup /dev/loop2 for instance to point out to
/dev/hda2, tell it what type of encryption and feed it the key. Then run
swapon /dev/loop2 instead of /dev/hda2, then your swap is encrypted.
I've done this by hand a while back and it worked, never tryied automating
it in the init scripts.
 
> Those are at kerneli.org, but don't expect them to be added to the
> mainstream kernels just yet. Apart from coding style and so on (which
> could be a reason), Linus won't let it happen just yet, but eventually it
> will, so just go help them and it will be in the mainstream kernels soon
> enough.
> 
They also aren't getting included due to the US's munitions export
laws. Yes, cryptography falls under the same rules as 50mm shells, and
nukes. So don't expect the kerneli.org patches to get merged until after
those rules go away. Since Linus is in the US, his code and the whole
kernel falls under US export law, if he adds encryption.



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 15:31:08 2000
Received: by humbolt.nl.linux.org id <S92203AbQHGN3y>;
	Mon, 7 Aug 2000 15:29:54 +0200
Received: from ip-gw7-4.dirtbike.net ([207.246.248.4]:48141 "HELO
        ip-gw7-4.dirtbike.net") by humbolt.nl.linux.org with SMTP
	id <S92202AbQHGN3f>; Mon, 7 Aug 2000 15:29:35 +0200
Received: (qmail 18277 invoked by alias); 7 Aug 2000 12:40:54 -0000
Received: from unknown (HELO pc.3sourcetech.com) (137.132.93.151)
  by ip-gw7-4.dirtbike.net with SMTP; 7 Aug 2000 12:40:54 -0000
Message-Id: <4.3.2.7.0.20000807211521.00a9a340@207.246.248.4>
X-Sender: jeff@3sourcetech.com@207.246.248.4
X-Mailer: QUALCOMM Windows Eudora Version 4.3.2
Date:   Mon, 07 Aug 2000 21:30:56 +0800
To:     kernel-audit@nl.linux.org
From:   "jeff@3SOURCE" <jeff@3sourcetech.com>
Subject: Re: TEST
In-Reply-To: <Pine.BSF.4.21.0008070912390.31053-100000@poindexter.wirehu
 b.nl>
References: <20000807014004.A7264@fdragon.lan>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"; format=flowed
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Actually, why not just jump over to OpenBSD instead of having to port things?
It seems like having to re-invent the wheel.

The way I see things, Linux appears to be way fragmented - what with
LIDS, Bastille, kerneli etc and all these patches, just to ride on top of the
kernel in order to get it to do the things we want... (of which would include
security - one of OpenBSD's most famous strength)

What ~are~ the project objectives of Linux anyway? I haven't seen any
(but perhaps I am wrong - correct me if you will). Good examples of
project statements would be (of course) like that of OpenBSD's and
NetBSD's (available at their respective .org's) Don't you think that perhaps
it is time we should start creating such objectives for Linux? (or perhaps
Linux is meant to be "free" in that sense, allowing each distribution
to make its own decision as to project goals (but this has unfortunately 
resulted
IMO too many distributions)???)

I would have hoped that the guys would have done something to Linux,
considering the news quite some time ago. Unfortunately, as the traffic
on this list has shown, nothing much seems to be in the way (or at least
not according to the traffic indications..)


-------------------------------------------------------------------------------------------
--- This Application has reported a 'Not My Fault' in module KRNL.EXE in 
line 0688:4EEE ---
--- 
---
--- Press any key to do 
nothing...                                                      ---
-------------------------------------------------------------------------------------------

peace to all *nix's
- jeff

==============

At 03:20 PM Monday 7/8/00, you wrote:
>On Mon, 7 Aug 2000, Fire Dragon wrote:
>
> > On Mon, Aug 07, 2000 at 01:15:38AM +0000, James Stevenson wrote:
> >
> > I know the current kernel is incapable of handling encryption (yes I know
> > about kerneli.org and the patches there...) but I'm kind of wondering how
> > much trouble it would be to actually add such a feature.
>
>have no idea, but if you can encrypt filesystems, why then not a swapfile
>(yes file), improving on swapfile performance would be greatly
>appreciapted by people anyway. You could also look into creating an
>encrypted swap as you are doing now, by patching your kernel first with
>kerneli.org patches.
>
> > Then again without encrypted file systems this is a bit pointless...
> >
>
>Those are at kerneli.org, but don't expect them to be added to the
>mainstream kernels just yet. Apart from coding style and so on (which
>could be a reason), Linus won't let it happen just yet, but eventually it
>will, so just go help them and it will be in the mainstream kernels soon
>enough.
>
> > ttylz
>
>Hope this helps,
>         Lennie.
>
>
>Kernel-audit:  discussion list for security and the linux kernel
>Archive:       http://mail.nl.linux.org/kernel-audit/


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 17:31:44 2000
Received: by humbolt.nl.linux.org id <S92207AbQHGPaW>;
	Mon, 7 Aug 2000 17:30:22 +0200
Received: from brutus.conectiva.com.br ([200.250.58.146]:14323 "EHLO
        duckman.distro.conectiva") by humbolt.nl.linux.org with ESMTP
	id <S92209AbQHGPaI>; Mon, 7 Aug 2000 17:30:08 +0200
Received: from localhost (riel@localhost)
	by duckman.distro.conectiva (8.9.3/8.8.7) with ESMTP id MAA25126;
	Mon, 7 Aug 2000 12:29:39 -0300
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Mon, 7 Aug 2000 12:29:39 -0300 (BRST)
From:   Rik van Riel <riel@conectiva.com.br>
X-Sender: riel@duckman.distro.conectiva
To:     "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>
cc:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
In-Reply-To: <Pine.LNX.4.21.0008070905570.7070-100000@yinyang.hjsoft.com>
Message-ID: <Pine.LNX.4.21.0008071217330.25008-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, Mr. Shannon Aldinger wrote:
> On Mon, 7 Aug 2000, L. Besselink wrote:
> > On Mon, 7 Aug 2000, Fire Dragon wrote:
> > 
> > Those are at kerneli.org, but don't expect them to be added to the
> > mainstream kernels just yet. Apart from coding style and so on (which
> > could be a reason), Linus won't let it happen just yet, but eventually it
> > will, so just go help them and it will be in the mainstream kernels soon
> > enough.
>
> They also aren't getting included due to the US's munitions export
> laws. Yes, cryptography falls under the same rules as 50mm shells, and
> nukes. So don't expect the kerneli.org patches to get merged until after
> those rules go away. Since Linus is in the US, his code and the whole
> kernel falls under US export law, if he adds encryption.

Which doesn't really matter.

Linux distributors from outside of the US (SuSE, Conectiva,
TurboLinux (the asian branch), etc...) are very much allowed
to add strong encryption to their distribution and "even" sell
those CDs to the US...

If there is some demand by people for linux distributions
that include all these encrypted-storage goodies, I'm sure
one or more of the Linux distributors can be persuaded to
start shipping with them.

<shameless plug>
Conectiva already ships with Free/SWAN and some other (network)
security things. No encrypted storage drivers that I know off,
but if there's enough interest I may be able to persuade the
people here to include that too...
</shameless plug>

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 17:37:46 2000
Received: by humbolt.nl.linux.org id <S92231AbQHGPgX>;
	Mon, 7 Aug 2000 17:36:23 +0200
Received: from brutus.conectiva.com.br ([200.250.58.146]:19188 "EHLO
        duckman.distro.conectiva") by humbolt.nl.linux.org with ESMTP
	id <S92219AbQHGPf7>; Mon, 7 Aug 2000 17:35:59 +0200
Received: from localhost (riel@localhost)
	by duckman.distro.conectiva (8.9.3/8.8.7) with ESMTP id MAA25152
	for <kernel-audit@nl.linux.org>; Mon, 7 Aug 2000 12:35:53 -0300
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Mon, 7 Aug 2000 12:35:53 -0300 (BRST)
From:   Rik van Riel <riel@conectiva.com.br>
X-Sender: riel@duckman.distro.conectiva
To:     kernel-audit@nl.linux.org
Subject: Re: TEST
In-Reply-To: <4.3.2.7.0.20000807211521.00a9a340@207.246.248.4>
Message-ID: <Pine.LNX.4.21.0008071230140.25008-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, jeff@3SOURCE wrote:

> Actually, why not just jump over to OpenBSD instead of having to
> port things? It seems like having to re-invent the wheel.
> 
> The way I see things, Linux appears to be way fragmented

> What ~are~ the project objectives of Linux anyway? I haven't
> seen any (but perhaps I am wrong - correct me if you will). Good
> examples of project statements would be (of course) like that of
> OpenBSD's and NetBSD's

Ahh, but now you're comparing all of Linux to two _specific_
BSD projects...

> Don't you think that perhaps it is time we should start creating
> such objectives for Linux?

s/for Linux/for our Linux project/

> or perhaps Linux is meant to be "free" in that sense, allowing
> each distribution to make its own decision as to project goals

Indeed it is. And yes, this has resulted in a lot of
distributions, but that isn't much of a problem since
they mostly copy each other's work instead of reinventing
the wheel.

If you want to do something for Linux security -- maybe
bring together some of the projects or integrate the
existing security patches in a distribution -- then you
should probably define the goals of that project, but
there is, IMHO, not much sense in defining an overall
"project goal" for Linux  (because it is used in everything
from video recorders to handhelds, to PCs, to Origins).

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 17:50:58 2000
Received: by humbolt.nl.linux.org id <S92211AbQHGPtk>;
	Mon, 7 Aug 2000 17:49:40 +0200
Received: from ppp104-yorkpa.netrax.net ([205.231.165.104]:41990 "EHLO
        yinyang.hjsoft.com") by humbolt.nl.linux.org with ESMTP
	id <S92210AbQHGPtG>; Mon, 7 Aug 2000 17:49:06 +0200
Received: from localhost (god@localhost)
	by yinyang.hjsoft.com (8.11.0.Beta1/8.10.1) with ESMTP id e77Fxlr07417
	for <kernel-audit@nl.linux.org>; Mon, 7 Aug 2000 11:59:47 -0400
Date:   Mon, 7 Aug 2000 11:59:47 -0400 (EDT)
From:   "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>
Reply-To: god@yinyang.hjsoft.com
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
In-Reply-To: <Pine.LNX.4.21.0008071217330.25008-100000@duckman.distro.conectiva>
Message-ID: <Pine.LNX.4.21.0008071151370.7070-100000@yinyang.hjsoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, Rik van Riel wrote:

> On Mon, 7 Aug 2000, Mr. Shannon Aldinger wrote:
> >
> > They also aren't getting included due to the US's munitions export
> > laws. Yes, cryptography falls under the same rules as 50mm shells, and
> > nukes. So don't expect the kerneli.org patches to get merged until after
> > those rules go away. Since Linus is in the US, his code and the whole
> > kernel falls under US export law, if he adds encryption.
> 
> Which doesn't really matter.
> 
It does matter since the official kernel source patches come from the US.
Importing to US isn't a problem, exporting from is. That is why
kerneli.org is hosted outside the US.

> Linux distributors from outside of the US (SuSE, Conectiva, TurboLinux
> (the asian branch), etc...) are very much allowed to add strong
> encryption to their distribution and "even" sell those CDs to the
> US...
> 
Importing to US is not a problem.

> <shameless plug>
> Conectiva already ships with Free/SWAN and some other (network)
> security things. No encrypted storage drivers that I know off,
> but if there's enough interest I may be able to persuade the
> people here to include that too...
> </shameless plug>
> 
If exporting from US isn't a problem as you implied above, then why
doesn't Henry Spencer, et al accept any code from a US citizen or a person
who happens to be in the US at the time? If all distributions and kernel
source were imported to the US, then you would have a point. As it stands
the US still has stupid restrictions on computer software and hardware
that can be exported, cryptography is the most restricted.



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 18:06:47 2000
Received: by humbolt.nl.linux.org id <S92210AbQHGQFM>;
	Mon, 7 Aug 2000 18:05:12 +0200
Received: from brutus.conectiva.com.br ([200.250.58.146]:33528 "EHLO
        duckman.distro.conectiva") by humbolt.nl.linux.org with ESMTP
	id <S92208AbQHGQEp>; Mon, 7 Aug 2000 18:04:45 +0200
Received: from localhost (riel@localhost)
	by duckman.distro.conectiva (8.9.3/8.8.7) with ESMTP id NAA25377;
	Mon, 7 Aug 2000 13:04:19 -0300
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Mon, 7 Aug 2000 13:04:19 -0300 (BRST)
From:   Rik van Riel <riel@conectiva.com.br>
X-Sender: riel@duckman.distro.conectiva
To:     "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>
cc:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
In-Reply-To: <Pine.LNX.4.21.0008071151370.7070-100000@yinyang.hjsoft.com>
Message-ID: <Pine.LNX.4.21.0008071301420.25008-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, Mr. Shannon Aldinger wrote:
> On Mon, 7 Aug 2000, Rik van Riel wrote:
> > On Mon, 7 Aug 2000, Mr. Shannon Aldinger wrote:
> > >
> > > They also aren't getting included due to the US's munitions export
> > > laws. Yes, cryptography falls under the same rules as 50mm shells, and
> > > nukes. So don't expect the kerneli.org patches to get merged until after
> > > those rules go away. Since Linus is in the US, his code and the whole
> > > kernel falls under US export law, if he adds encryption.
> > 
> > Which doesn't really matter.
>
> It does matter since the official kernel source patches come
> from the US. Importing to US isn't a problem, exporting from is.
> That is why kerneli.org is hosted outside the US.

90% of the users seem to use the kernel image supplied by
the distribution, not the official kernel source. That is
why I don't think it matters a lot that crypto export from
the US is so limited.

> > Linux distributors from outside of the US (SuSE, Conectiva, TurboLinux
> > (the asian branch), etc...) are very much allowed to add strong
> > encryption to their distribution and "even" sell those CDs to the
> > US...
>
> Importing to US is not a problem.

Exactly. Users who care about security should nag some non-US
Linux distributor about security and simply get their distribution
from a non-US company.

(this could also be a nice action to influence the US govt.)

> > <shameless plug>
> > Conectiva already ships with Free/SWAN and some other (network)
> > security things. No encrypted storage drivers that I know off,
> > but if there's enough interest I may be able to persuade the
> > people here to include that too...
> > </shameless plug>
>
> If exporting from US isn't a problem as you implied above,

Where did I say that?

> If all distributions and kernel source were imported to the US,
> then you would have a point. As it stands the US still has
> stupid restrictions on computer software and hardware that can
> be exported, cryptography is the most restricted.

Who cares? You don't have to use a US-based distribution...

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug  7 19:39:04 2000
Received: by humbolt.nl.linux.org id <S92208AbQHGRhm>;
	Mon, 7 Aug 2000 19:37:42 +0200
Received: from spk-49.ipeg.com ([206.96.95.49]:35600 "EHLO fury.localdomain")
	by humbolt.nl.linux.org with ESMTP id <S92178AbQHGRhK>;
	Mon, 7 Aug 2000 19:37:10 +0200
Received: from localhost (sjp@localhost)
	by fury.localdomain (8.9.3/8.9.3) with ESMTP id KAA26316;
	Mon, 7 Aug 2000 10:28:15 -0700
X-Authentication-Warning: fury.localdomain: sjp owned process doing -bs
Date:   Mon, 7 Aug 2000 10:28:15 -0700 (PDT)
From:   Pollei <sjp@toolbuilders.com>
X-Sender: sjp@fury.localdomain
To:     Rik van Riel <riel@conectiva.com.br>
cc:     "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>,
        kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
In-Reply-To: <Pine.LNX.4.21.0008071301420.25008-100000@duckman.distro.conectiva>
Message-ID: <Pine.LNX.4.10.10008071026460.26273-100000@fury.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, Rik van Riel wrote:

> On Mon, 7 Aug 2000, Mr. Shannon Aldinger wrote:
> > On Mon, 7 Aug 2000, Rik van Riel wrote:
> > > On Mon, 7 Aug 2000, Mr. Shannon Aldinger wrote:
> > > >
> > > > They also aren't getting included due to the US's munitions export
> > > > laws. Yes, cryptography falls under the same rules as 50mm shells, and
> > > > nukes. So don't expect the kerneli.org patches to get merged until after
> > > > those rules go away. Since Linus is in the US, his code and the whole
> > > > kernel falls under US export law, if he adds encryption.
> > > 
> > > Which doesn't really matter.
> >
> > It does matter since the official kernel source patches come
> > from the US. Importing to US isn't a problem, exporting from is.
> > That is why kerneli.org is hosted outside the US.
www.kernel.org now also has the patches and they are planning on
intergrating them for 2.5 . The laws have changed.


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 00:40:14 2000
Received: by humbolt.nl.linux.org id <S92246AbQHGWiw>;
	Tue, 8 Aug 2000 00:38:52 +0200
Received: from terra.geo.uu.nl ([131.211.29.16]:996 "EHLO terra.geo.uu.nl")
	by humbolt.nl.linux.org with ESMTP id <S92243AbQHGWiO>;
	Tue, 8 Aug 2000 00:38:14 +0200
Received: from localhost.gumbynet.org (root@localhost.gumbynet.org [203.42.225.1])
	by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id AAA14834
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 00:38:06 +0200 (MET DST)
Received: from box3n.gumbynet.org (box3n.gumbynet.org [203.43.214.254])
	by localhost.gumbynet.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id IAA03072
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 08:38:00 +1000
Received: from localhost (fyre@localhost)
	by box3n.gumbynet.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id IAA27130
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 08:38:05 +1000
Date:   Tue, 8 Aug 2000 08:38:04 +1000 (EST)
From:   Tim Robbins <fyre@box3n.gumbynet.org>
To:     kernel-audit@nl.linux.org
Subject: Re: TEST
In-Reply-To: <20000807014004.A7264@fdragon.lan>
Message-ID: <Pine.LNX.4.21.0008080818580.27097-100000@box3n.gumbynet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

> OpenBSD seems to have something up on linux now in the way of security. A
> feature I rather like and am almost tempted to learn enough kernel hacking
> to port myself. The feature I'm speaking of happens to be encrypted swap.

Would that not be incredibly slow? On a low end machine that might halve
performance in the best case. It might be useful if you're paranoid that
the police are going to raid your house and go hunting through a few
hundred megabytes of swap space looking for evidence or
something. Encrypting swap would offer protection from that kind of thing,
but then again, the police will always have ways of making your life
difficult..

For the average Linux server on which nobody but the superuser can read
the swapspace, I don't see a lot of point in encrypting it.

Just my 1.2 cents (Australian dollar ain't worth much these days)

--
Tim Robbins
fyre@box3n.gumbynet.org


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 00:52:04 2000
Received: by humbolt.nl.linux.org id <S92247AbQHGWun>;
	Tue, 8 Aug 2000 00:50:43 +0200
Received: from terra.geo.uu.nl ([131.211.29.16]:13284 "EHLO terra.geo.uu.nl")
	by humbolt.nl.linux.org with ESMTP id <S92243AbQHGWuM>;
	Tue, 8 Aug 2000 00:50:12 +0200
Received: from localhost.gumbynet.org (root@localhost.gumbynet.org [203.42.225.1])
	by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id AAA15040
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 00:50:09 +0200 (MET DST)
Received: from box3n.gumbynet.org (box3n.gumbynet.org [203.43.214.254])
	by localhost.gumbynet.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id IAA03127
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 08:50:05 +1000
Received: from localhost (fyre@localhost)
	by box3n.gumbynet.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id IAA27155
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 08:50:09 +1000
Date:   Tue, 8 Aug 2000 08:50:08 +1000 (EST)
From:   Tim Robbins <fyre@box3n.gumbynet.org>
To:     kernel-audit@nl.linux.org
Subject: Re: TEST
In-Reply-To: <Pine.LNX.4.21.0008071230140.25008-100000@duckman.distro.conectiva>
Message-ID: <Pine.LNX.4.21.0008080840330.27097-100000@box3n.gumbynet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

> Indeed it is. And yes, this has resulted in a lot of
> distributions, but that isn't much of a problem since
> they mostly copy each other's work instead of reinventing
> the wheel.

Yes, great point. Most (all?) Linux distributions use the same set of
packages, they just have different installation systems, different default
configurations, etc. THat's a simplistic point of view. 

You can't change the way a distribution maker choses to configure the
packages, but if you find a security flaw in a package and contribute it,
the security of all distributions benefit. There are always going to be
different distributions, but under the hood they are all pretty similar.

Tim

--
Tim Robbins
fyre@box3n.gumbynet.org


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 01:10:37 2000
Received: by humbolt.nl.linux.org id <S92249AbQHGXJZ>;
	Tue, 8 Aug 2000 01:09:25 +0200
Received: from lemuria.borgfelde.ricardo.de ([195.244.103.65]:36625 "HELO
        mail.lemuria.org") by humbolt.nl.linux.org with SMTP
	id <S92243AbQHGXIn>; Tue, 8 Aug 2000 01:08:43 +0200
Received: from lemuria.org by mail.lemuria.org
	via rsmtp with bsmtp
	id <m13LvtY-0015wGC@mail.lemuria.org>
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 01:01:20 +0200 (MEST)
	(Smail-3.2 1996-Jul-4 #1 built 1999-Nov-8)
Received: by lemuria.org
	via sendmail with stdio
	id <m13LrTc-000HfOC@lemuria.org>
	for kernel-audit@nl.linux.org; Mon, 7 Aug 2000 20:18:16 +0200 (MEST)
	(Smail-3.2 1996-Jul-4 #1 built 1999-Nov-8)
Date:   Mon, 7 Aug 2000 20:18:15 +0200
From:   Tom Vogt <tom@lemuria.org>
To:     kernel-audit@nl.linux.org
Subject: Re: TEST
Message-ID: <20000807201815.A4691@lemuria.org>
References: <20000807001427.D7983@braecklein.freeserve.co.uk> <Pine.LNX.4.21.0008070115150.8021-100000@linux.home> <20000807014004.A7264@fdragon.lan>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="UugvWAfsgieZRqgk"
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <20000807014004.A7264@fdragon.lan>
X-Privacy: If you can, please encrypt your mails - finger for key
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


--UugvWAfsgieZRqgk
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: quoted-printable

Fire Dragon <fdragon@io.com> wrote:
> I know the current kernel is incapable of handling encryption (yes I know
> about kerneli.org and the patches there...) but I'm kind of wondering how
> much trouble it would be to actually add such a feature.

you can hack it together - use a swap file instead of swap device, and do
it on an encrypted filesystem.


> Then again without encrypted file systems this is a bit pointless...

there are a couple around. it's just that last time I checked they all were
unsatisfactory.



--=20
"The net treats censorship as a malfunction and re-routes around it."
(John Gilmore)

--UugvWAfsgieZRqgk
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.0 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5jv1mSd75SPXqTkERAY3gAJwLNeBFCsEWWEbbz7dFVoS1v//2/ACdE6uo
9e3ffb4Rm68Ug2i0iRNsI+w=
=w2un
-----END PGP SIGNATURE-----

--UugvWAfsgieZRqgk--

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 08:50:32 2000
Received: by humbolt.nl.linux.org id <S92243AbQHHGtK>;
	Tue, 8 Aug 2000 08:49:10 +0200
Received: from lemuria.borgfelde.ricardo.de ([195.244.103.65]:36100 "HELO
        mail.lemuria.org") by humbolt.nl.linux.org with SMTP
	id <S92164AbQHHGsj>; Tue, 8 Aug 2000 08:48:39 +0200
Received: from lemuria.org by mail.lemuria.org
	via rsmtp with bsmtp
	id <m13M2zd-0015wGC@mail.lemuria.org>
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 08:36:05 +0200 (MEST)
	(Smail-3.2 1996-Jul-4 #1 built 1999-Nov-8)
Received: by lemuria.org
	via sendmail with stdio
	id <m13M2uL-000HfOC@lemuria.org>
	for kernel-audit@nl.linux.org; Tue, 8 Aug 2000 08:30:37 +0200 (MEST)
	(Smail-3.2 1996-Jul-4 #1 built 1999-Nov-8)
Date:   Tue, 8 Aug 2000 08:30:37 +0200
From:   Tom Vogt <tom@lemuria.org>
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
Message-ID: <20000808083037.A6571@lemuria.org>
References: <Pine.LNX.4.21.0008071151370.7070-100000@yinyang.hjsoft.com> <Pine.LNX.4.21.0008071301420.25008-100000@duckman.distro.conectiva>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <Pine.LNX.4.21.0008071301420.25008-100000@duckman.distro.conectiva>
X-Privacy: If you can, please encrypt your mails - finger for key
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Rik van Riel <riel@conectiva.com.br> wrote:
> 90% of the users seem to use the kernel image supplied by
> the distribution, not the official kernel source. That is
> why I don't think it matters a lot that crypto export from
> the US is so limited.

it is, because you have to make sure not to accept patches from US
residents, for example. as I learned from hugh daniels, the US freaks
sometimes consider it "export" when US citizen teach non-US citizen what
they know. so there's a lot of ways your work could get "tainted".


-- 
"The net treats censorship as a malfunction and re-routes around it."
(John Gilmore)

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:24:19 2000
Received: by humbolt.nl.linux.org id <S92314AbQHHKW0>;
	Tue, 8 Aug 2000 12:22:26 +0200
Received: from [63.226.207.58] ([63.226.207.58]:9990 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92164AbQHHKV5>;
	Tue, 8 Aug 2000 12:21:57 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 9DB444333B5; Sun,  6 Aug 2000 21:11:33 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041133.9DB444333B5@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:11:33 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:27:11 2000
Received: by humbolt.nl.linux.org id <S92164AbQHHKWe>;
	Tue, 8 Aug 2000 12:22:34 +0200
Received: from [63.226.207.58] ([63.226.207.58]:13574 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92282AbQHHKV7>;
	Tue, 8 Aug 2000 12:21:59 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id C2D634333B9; Sun,  6 Aug 2000 21:12:33 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041233.C2D634333B9@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:12:33 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:28:50 2000
Received: by humbolt.nl.linux.org id <S92282AbQHHKWq>;
	Tue, 8 Aug 2000 12:22:46 +0200
Received: from [63.226.207.58] ([63.226.207.58]:13318 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92281AbQHHKV7>;
	Tue, 8 Aug 2000 12:21:59 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id CEE834333AE; Sun,  6 Aug 2000 21:09:47 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807040947.CEE834333AE@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:09:47 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:30:20 2000
Received: by humbolt.nl.linux.org id <S92281AbQHHKW7>;
	Tue, 8 Aug 2000 12:22:59 +0200
Received: from [63.226.207.58] ([63.226.207.58]:13062 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92269AbQHHKV6>;
	Tue, 8 Aug 2000 12:21:58 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 714D74333B4; Sun,  6 Aug 2000 21:11:18 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041118.714D74333B4@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:11:18 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:32:10 2000
Received: by humbolt.nl.linux.org id <S92269AbQHHKXQ>;
	Tue, 8 Aug 2000 12:23:16 +0200
Received: from [63.226.207.58] ([63.226.207.58]:12038 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92266AbQHHKV5>;
	Tue, 8 Aug 2000 12:21:57 +0200
Received: by mail.quasisoft.com (Postfix, from userid 504)
	id 6F1734333AA; Sun,  6 Aug 2000 20:06:44 -0700 (PDT)
Date:   Sun, 6 Aug 2000 20:06:44 -0700
From:   quasi@quasisoft.com
To:     kernel-audit@nl.linux.org
Subject: Re: TEST ; Non-exec stack patch
Message-ID: <20000806200644.B11383@quasisoft.com>
References: <20000807001427.D7983@braecklein.freeserve.co.uk> <Pine.LNX.4.21.0008070115150.8021-100000@linux.home>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <Pine.LNX.4.21.0008070115150.8021-100000@linux.home>; from mistral@stevenson.zetnet.co.uk on Mon, Aug 07, 2000 at 01:15:38AM +0000
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

> yep you are on this list
> i dont get any mail on it either :P
> 
> > As I don't seem to be getting anymail from this list, i'm
> > just checking to see if it is still alive.

Is there any chance of getting Solar Designer's non-exec stack patch features
included in the 2.4 kernel?  It has some other good features besides just the
non-exec stack.  Is this off-topic?

MasterCoder

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:33:40 2000
Received: by humbolt.nl.linux.org id <S92266AbQHHKX2>;
	Tue, 8 Aug 2000 12:23:28 +0200
Received: from [63.226.207.58] ([63.226.207.58]:14342 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92303AbQHHKWA>;
	Tue, 8 Aug 2000 12:22:00 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 9B49A4333B7; Sun,  6 Aug 2000 21:11:48 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041148.9B49A4333B7@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:11:48 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:35:40 2000
Received: by humbolt.nl.linux.org id <S92303AbQHHKXl>;
	Tue, 8 Aug 2000 12:23:41 +0200
Received: from [63.226.207.58] ([63.226.207.58]:14854 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92301AbQHHKWA>;
	Tue, 8 Aug 2000 12:22:00 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 1B3254333B0; Sun,  6 Aug 2000 21:10:17 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041017.1B3254333B0@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:10:17 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:37:10 2000
Received: by humbolt.nl.linux.org id <S92301AbQHHKXx>;
	Tue, 8 Aug 2000 12:23:53 +0200
Received: from [63.226.207.58] ([63.226.207.58]:14598 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92299AbQHHKWA>;
	Tue, 8 Aug 2000 12:22:00 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id DABFD4333AF; Sun,  6 Aug 2000 21:10:02 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041002.DABFD4333AF@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:10:02 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:38:50 2000
Received: by humbolt.nl.linux.org id <S92299AbQHHKYG>;
	Tue, 8 Aug 2000 12:24:06 +0200
Received: from [63.226.207.58] ([63.226.207.58]:14086 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92291AbQHHKV7>;
	Tue, 8 Aug 2000 12:21:59 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id CBC214333B6; Sun,  6 Aug 2000 21:12:03 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041203.CBC214333B6@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:12:03 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:40:10 2000
Received: by humbolt.nl.linux.org id <S92291AbQHHKYi>;
	Tue, 8 Aug 2000 12:24:38 +0200
Received: from [63.226.207.58] ([63.226.207.58]:13830 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92290AbQHHKV7>;
	Tue, 8 Aug 2000 12:21:59 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id C34A44333B8; Sun,  6 Aug 2000 21:12:18 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041218.C34A44333B8@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:12:18 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:42:00 2000
Received: by humbolt.nl.linux.org id <S92316AbQHHK1k>;
	Tue, 8 Aug 2000 12:27:40 +0200
Received: from [63.226.207.58] ([63.226.207.58]:11014 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92264AbQHHKV5>;
	Tue, 8 Aug 2000 12:21:57 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 79CD64333B3; Sun,  6 Aug 2000 21:11:03 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041103.79CD64333B3@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:11:03 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:43:51 2000
Received: by humbolt.nl.linux.org id <S92290AbQHHKZJ>;
	Tue, 8 Aug 2000 12:25:09 +0200
Received: from [63.226.207.58] ([63.226.207.58]:15878 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92309AbQHHKWB>;
	Tue, 8 Aug 2000 12:22:01 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id E1BDC4333AD; Sun,  6 Aug 2000 21:09:29 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807040929.E1BDC4333AD@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:09:29 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:45:40 2000
Received: by humbolt.nl.linux.org id <S92315AbQHHKZn>;
	Tue, 8 Aug 2000 12:25:43 +0200
Received: from [63.226.207.58] ([63.226.207.58]:15622 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92308AbQHHKWB>;
	Tue, 8 Aug 2000 12:22:01 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 249B84333B2; Sun,  6 Aug 2000 21:10:48 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041048.249B84333B2@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:10:48 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:47:20 2000
Received: by humbolt.nl.linux.org id <S92308AbQHHK0I>;
	Tue, 8 Aug 2000 12:26:08 +0200
Received: from [63.226.207.58] ([63.226.207.58]:15366 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92307AbQHHKWA>;
	Tue, 8 Aug 2000 12:22:00 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id A6E324333AC; Sun,  6 Aug 2000 21:09:14 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807040914.A6E324333AC@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:09:14 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:49:10 2000
Received: by humbolt.nl.linux.org id <S92307AbQHHK0d>;
	Tue, 8 Aug 2000 12:26:33 +0200
Received: from [63.226.207.58] ([63.226.207.58]:15110 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92306AbQHHKWA>;
	Tue, 8 Aug 2000 12:22:00 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 14B0C4333B1; Sun,  6 Aug 2000 21:10:33 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041033.14B0C4333B1@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:10:33 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:50:50 2000
Received: by humbolt.nl.linux.org id <S92306AbQHHK0q>;
	Tue, 8 Aug 2000 12:26:46 +0200
Received: from [63.226.207.58] ([63.226.207.58]:8454 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92313AbQHHKWB>;
	Tue, 8 Aug 2000 12:22:01 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 013FA4333BA; Sun,  6 Aug 2000 21:12:48 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041248.013FA4333BA@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:12:48 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:52:30 2000
Received: by humbolt.nl.linux.org id <S92313AbQHHK1A>;
	Tue, 8 Aug 2000 12:27:00 +0200
Received: from [63.226.207.58] ([63.226.207.58]:16134 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92310AbQHHKWB>;
	Tue, 8 Aug 2000 12:22:01 +0200
Received: by mail.quasisoft.com (Postfix, from userid 0)
	id 174504333BB; Sun,  6 Aug 2000 21:13:03 -0700 (PDT)
To:     kernel-audit@nl.linux.org
Subject: TEST
Message-Id: <20000807041303.174504333BB@mail.quasisoft.com>
Date:   Sun,  6 Aug 2000 21:13:03 -0700 (PDT)
From:   root@quasisoft.com (root)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Stop blocking me.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 12:55:40 2000
Received: by humbolt.nl.linux.org id <S92349AbQHHKyI>;
	Tue, 8 Aug 2000 12:54:08 +0200
Received: from office.mandrakesoft.com ([195.68.114.34]:1529 "EHLO
        test1.mandrakesoft.com") by humbolt.nl.linux.org with ESMTP
	id <S92310AbQHHKxr>; Tue, 8 Aug 2000 12:53:47 +0200
Received: by test1.mandrakesoft.com (Postfix, from userid 500)
	id A57563712; Tue,  8 Aug 2000 11:50:35 +0200 (CEST)
To:     quasi@quasisoft.com
Cc:     kernel-audit@nl.linux.org
Subject: Re: TEST ; Non-exec stack patch
References: <20000807001427.D7983@braecklein.freeserve.co.uk>
	<Pine.LNX.4.21.0008070115150.8021-100000@linux.home>
	<20000806200644.B11383@quasisoft.com>
From:   Yoann Vandoorselaere <yoann@mandrakesoft.com>
Date:   08 Aug 2000 11:50:35 +0200
In-Reply-To: quasi@quasisoft.com's message of "Sun, 6 Aug 2000 20:06:44 -0700"
Message-ID: <m34s4wf5ec.fsf@test1.mandrakesoft.com>
Lines:  32
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

quasi@quasisoft.com writes:

> > yep you are on this list
> > i dont get any mail on it either :P
> > 
> > > As I don't seem to be getting anymail from this list, i'm
> > > just checking to see if it is still alive.
> 
> Is there any chance of getting Solar Designer's non-exec stack patch features
> included in the 2.4 kernel?  

No.

> It has some other good features besides just the
> non-exec stack.  

So create a clean patch with *good* and arguable feature only.
Then send it to Lkml.

> Is this off-topic?

Yes, it was discussed thousand of time;
just search for thread containing 'LUID' and 'general security'
on lkml archives.

-- 
		-- Yoann http://www.mandrakesoft.com/~yoann/
		
- Windows  Where do you want to go today?
- MacOS	   Where do you want to be tomorrow?
- Linux	   Are you coming, or what?
	 -- Bill Maidment

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 13:12:01 2000
Received: by humbolt.nl.linux.org id <S92309AbQHHLKu>;
	Tue, 8 Aug 2000 13:10:50 +0200
Received: from zada.math.leidenuniv.nl ([132.229.231.3]:37899 "EHLO
        zada.math.leidenuniv.nl") by humbolt.nl.linux.org with ESMTP
	id <S92264AbQHHLKH>; Tue, 8 Aug 2000 13:10:07 +0200
Received: from mara.math.leidenuniv.nl (mara.math.leidenuniv.nl [132.229.232.80])
	by zada.math.leidenuniv.nl (8.9.3/8.9.3) with ESMTP id NAA26436;
	Tue, 8 Aug 2000 13:09:48 +0200
Date:   Tue, 8 Aug 2000 13:09:48 +0200 (MEST)
From:   Lennert Buytenhek <buytenh@gnu.org>
X-Sender: buytenh@mara.math.leidenuniv.nl
To:     root <root@quasisoft.com>
cc:     kernel-audit@nl.linux.org
Subject: Re: TEST
In-Reply-To: <20000807041303.174504333BB@mail.quasisoft.com>
Message-ID: <Pine.LNX.4.21.0008081309340.7474-100000@mara.math.leidenuniv.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


Stop spamming me.


On Sun, 6 Aug 2000, root wrote:

> Stop blocking me.
> 
> Kernel-audit:  discussion list for security and the linux kernel
> Archive:       http://mail.nl.linux.org/kernel-audit/
> 


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 13:29:30 2000
Received: by humbolt.nl.linux.org id <S92264AbQHHL17>;
	Tue, 8 Aug 2000 13:27:59 +0200
Received: from [203.129.250.50] ([203.129.250.50]:45073 "HELO
        beta.indsoft.co.in") by humbolt.nl.linux.org with SMTP
	id <S92320AbQHHL10>; Tue, 8 Aug 2000 13:27:26 +0200
Received: (qmail 16977 invoked from network); 8 Aug 2000 11:16:31 -0000
Received: from unknown (HELO linux.indsoft.com) (192.168.1.1)
  by 203.129.250.50 with SMTP; 8 Aug 2000 11:16:31 -0000
Date:   Tue, 8 Aug 2000 16:47:54 +0530 (IST)
From:   "RajKumar S." <raj@indsoft.co.in>
To:     kernel-audit@nl.linux.org
cc:     root <root@quasisoft.com>
Subject: Re: TEST
In-Reply-To: <Pine.LNX.4.21.0008081309340.7474-100000@mara.math.leidenuniv.nl>
Message-ID: <Pine.LNX.4.10.10008081645070.9336-100000@linux.indsoft.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


On Tue, 8 Aug 2000, Lennert Buytenhek wrote:

 |
 |Stop spamming me.
 |
 |
 |On Sun, 6 Aug 2000, root wrote:
 |
 |> Stop blocking me.

is this some kind of automatic mail thing. i got two doses of 8 mails each
with very little time between.

hey root(@qua...) you are not being blocked


raj


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 15:07:33 2000
Received: by humbolt.nl.linux.org id <S92318AbQHHNGU>;
	Tue, 8 Aug 2000 15:06:20 +0200
Received: from tclux14.cec.lu ([158.169.9.51]:26071 "EHLO tclux14.cec.lu")
	by humbolt.nl.linux.org with ESMTP id <S92310AbQHHNFt>;
	Tue, 8 Aug 2000 15:05:49 +0200
Received: from tclux14.cec.lu (localhost [127.0.0.1])
	by tclux14.cec.lu (8.9.3+Sun/8.9.3) with ESMTP id PAA17367;
	Tue, 8 Aug 2000 15:04:58 +0200 (MET DST)
Received: from ex3lujmoims02.cec.eu.int ([158.169.9.55])
	by tclux14.cec.lu (8.9.3+Sun/8.9.3) with ESMTP id PAA17359;
	Tue, 8 Aug 2000 15:04:57 +0200 (MET DST)
Received: by ex3lujmoims02 with Internet Mail Service (5.5.2650.21)
	id <Q3NPCGWV>; Tue, 8 Aug 2000 15:05:40 +0200
Message-ID: <71486F57BD42D411B2A7009027CA380E2FC801@ex2beimcombx03>
From:   "YADABA Honore (TAXUD)" <Honore.Yadaba@cec.eu.int>
To:     kernel-audit@nl.linux.org
Cc:     root <root@quasisoft.com>
Subject: RE: TEST
Date:   Tue, 8 Aug 2000 15:05:37 +0200 
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2650.21)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

I've got the same packet few minutes ago. The test seems to be ok.

YADABA

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 15:12:02 2000
Received: by humbolt.nl.linux.org id <S92320AbQHHNKa>;
	Tue, 8 Aug 2000 15:10:30 +0200
Received: from user34-107.jakinternet.co.uk ([212.41.34.107]:4364 "EHLO
        linux.home") by humbolt.nl.linux.org with ESMTP id <S92310AbQHHNJ5>;
	Tue, 8 Aug 2000 15:09:57 +0200
Received: from localhost (mistral@localhost)
	by linux.home (8.9.3/8.9.3) with ESMTP id OAA20573;
	Mon, 7 Aug 2000 14:41:56 GMT
Date:   Mon, 7 Aug 2000 14:41:56 +0000 (GMT)
From:   James Stevenson <mistral@stevenson.zetnet.co.uk>
To:     "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>
cc:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
In-Reply-To: <Pine.LNX.4.21.0008070905570.7070-100000@yinyang.hjsoft.com>
Message-ID: <Pine.LNX.4.21.0008071439450.20543-100000@linux.home>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


Hi

one of the things that i though was what is the point in encrypting the
swap file under linux i do not see any benifits
it would be slower
no added security (/proc/kcore ?) unless the person who set the system
up has left the swap world readable (duh) if you are root you can just
poke around the processes memory anyway

cya
	JAmes


On Mon, 7 Aug 2000, Mr. Shannon Aldinger wrote:

> On Mon, 7 Aug 2000, L. Besselink wrote:
> 
> > On Mon, 7 Aug 2000, Fire Dragon wrote:
> > 
> > have no idea, but if you can encrypt filesystems, why then not a swapfile
> > (yes file), improving on swapfile performance would be greatly
> > appreciapted by people anyway. You could also look into creating an
> > encrypted swap as you are doing now, by patching your kernel first with
> > kerneli.org patches.
> >
> These patches use the loopback feature, so if your swap partition is
> /dev/hda2. The you setup /dev/loop2 for instance to point out to
> /dev/hda2, tell it what type of encryption and feed it the key. Then run
> swapon /dev/loop2 instead of /dev/hda2, then your swap is encrypted.
> I've done this by hand a while back and it worked, never tryied automating
> it in the init scripts.
>  
> > Those are at kerneli.org, but don't expect them to be added to the
> > mainstream kernels just yet. Apart from coding style and so on (which
> > could be a reason), Linus won't let it happen just yet, but eventually it
> > will, so just go help them and it will be in the mainstream kernels soon
> > enough.
> > 
> They also aren't getting included due to the US's munitions export
> laws. Yes, cryptography falls under the same rules as 50mm shells, and
> nukes. So don't expect the kerneli.org patches to get merged until after
> those rules go away. Since Linus is in the US, his code and the whole
> kernel falls under US export law, if he adds encryption.
> 
> 
> 
> Kernel-audit:  discussion list for security and the linux kernel
> Archive:       http://mail.nl.linux.org/kernel-audit/
> 

-- 
---------------------------------------------
Check Out: http://www.users.zetnet.co.uk/james/
E-Mail: mistral@stevenson.zetnet.co.uk
  2:30pm  up 22:06,  8 users,  load average: 0.15, 0.35, 0.34


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 15:14:11 2000
Received: by humbolt.nl.linux.org id <S92322AbQHHNMd>;
	Tue, 8 Aug 2000 15:12:33 +0200
Received: from [63.226.207.58] ([63.226.207.58]:8964 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92321AbQHHNLD>;
	Tue, 8 Aug 2000 15:11:03 +0200
Received: by mail.quasisoft.com (Postfix, from userid 504)
	id B1B8E433398; Tue,  8 Aug 2000 06:15:30 -0700 (PDT)
Date:   Tue, 8 Aug 2000 06:15:30 -0700
From:   quasi@quasisoft.com
To:     kernel-audit@nl.linux.org
Subject: Re: TEST
Message-ID: <20000808061530.A2264@quasisoft.com>
References: <71486F57BD42D411B2A7009027CA380E2FC801@ex2beimcombx03>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <71486F57BD42D411B2A7009027CA380E2FC801@ex2beimcombx03>; from Honore.Yadaba@cec.eu.int on Tue, Aug 08, 2000 at 03:05:37PM +0200
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Alright, but I want to know how lm7@howell-stal.pl got in through postfix.
Port-forwarding was enabled on the external interface, if that had anything
to do with it.  Where is the hole in postfix?

-mc1

On Tue, Aug 08, 2000 at 03:05:37PM +0200, YADABA Honore (TAXUD) wrote:
> I've got the same packet few minutes ago. The test seems to be ok.
> 
> YADABA

-- 

http://www.quasisoft.com

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 15:29:41 2000
Received: by humbolt.nl.linux.org id <S92310AbQHHN2C>;
	Tue, 8 Aug 2000 15:28:02 +0200
Received: from itesec.hsc.fr ([192.70.106.33]:62734 "EHLO itesec.hsc.fr")
	by humbolt.nl.linux.org with ESMTP id <S92324AbQHHN1d>;
	Tue, 8 Aug 2000 15:27:33 +0200
Received: from groar.hsc.fr (hsc.hsc.fr [192.70.106.86])
	by itesec.hsc.fr (Postfix) with ESMTP id 09D3210EC1
	for <kernel-audit@nl.linux.org>; Tue,  8 Aug 2000 15:27:32 +0200 (CEST)
Received: by groar.hsc.fr (Postfix, from userid 1000)
	id AD2EC113F9; Tue,  8 Aug 2000 15:27:30 +0200 (CEST)
Date:   Tue, 8 Aug 2000 15:27:30 +0200
From:   Denis Ducamp <Denis.Ducamp@hsc.fr>
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
Message-ID: <20000808152730.H21469@hsc.fr>
References: <Pine.LNX.4.21.0008070905570.7070-100000@yinyang.hjsoft.com> <Pine.LNX.4.21.0008071439450.20543-100000@linux.home>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
X-Mailer: Mutt 1.0.1i
In-Reply-To: <Pine.LNX.4.21.0008071439450.20543-100000@linux.home>; from mistral@stevenson.zetnet.co.uk on Mon, Aug 07, 2000 at 02:41:56PM +0000
X-Mail: Fetchmail and Postfix forwarded over OpenSsh
X-Operating-System: Linux 2.2.16 - Slackware 7.0
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, Aug 07, 2000 at 02:41:56PM +0000, James Stevenson wrote:
> 
> Hi
> 
> one of the things that i though was what is the point in encrypting the
> swap file under linux i do not see any benifits
> it would be slower
> no added security (/proc/kcore ?) unless the person who set the system
> up has left the swap world readable (duh) if you are root you can just
> poke around the processes memory anyway

That has been done under OpenBSD because the author stopped his system and
found very interresting informations in the swap.

That exist against people physically stealing hard drives with swap.

Denis.

-- 
Denis.Ducamp@hsc.fr -- Hervé Schauer Consultants -- http://www.hsc.fr/

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 16:17:12 2000
Received: by humbolt.nl.linux.org id <S92323AbQHHOPt>;
	Tue, 8 Aug 2000 16:15:49 +0200
Received: from tmpil001.tmp.allied.com ([198.80.19.2]:63456 "HELO
        tmpil001.tmp.allied.com") by humbolt.nl.linux.org with SMTP
	id <S92199AbQHHOPc>; Tue, 8 Aug 2000 16:15:32 +0200
Received: from tmpnt701.allied.com (alliedsignal.com) by tmpil001.tmp.allied.com with SMTP id HAA09182
  (InterLock SMTP Gateway 3.0 for <kernel-audit@nl.linux.org>);
  Tue, 8 Aug 2000 07:15:23 -0700
Received: from 131.127.249.187 by tmpnt701.allied.com (InterScan E-Mail VirusWall NT); Tue, 08 Aug 2000 07:15:22 -0700
Received: by TMPCN190 with Internet Mail Service (5.5.2448.0)
	id <Q2WTBHYT>; Tue, 8 Aug 2000 07:15:21 -0700
Message-Id: <4B3EBD3B46D7D21194B30008C7B1C76505795886@OLTEX134>
From:   "Copeland, Matthew" <Matthew.Copeland@Honeywell.com>
To:     "'kernel-audit@nl.linux.org'" <kernel-audit@nl.linux.org>
Subject: RE: encrypting swap conversation
Date:   Tue, 8 Aug 2000 07:15:13 -0700 
X-Mailer: Internet Mail Service (5.5.2448.0)
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


Just a thought, everyone might want to go through the lkml archives and read
the recent thread on Crypto, since essentially this is entirely being
rehashed right here.  :)

Matthew M. Copeland

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 20:46:49 2000
Received: by humbolt.nl.linux.org id <S92350AbQHHSp1>;
	Tue, 8 Aug 2000 20:45:27 +0200
Received: from neodymium.btinternet.com ([194.73.73.83]:57984 "EHLO
        neodymium.btinternet.com") by humbolt.nl.linux.org with ESMTP
	id <S92345AbQHHSou>; Tue, 8 Aug 2000 20:44:50 +0200
Received: from [62.6.81.200] (helo=trinity.local)
	by neodymium.btinternet.com with esmtp (Exim 3.03 #83)
	id 13MEMc-0007iM-00; Tue, 08 Aug 2000 19:44:35 +0100
Received: from neo.local (davej@neo.local [172.16.0.4])
	by trinity.local (8.9.3/8.9.3) with ESMTP id TAA02971;
	Tue, 8 Aug 2000 19:43:38 +0100
From:   davej@suse.de
Date:   Tue, 8 Aug 2000 19:44:17 +0000 (GMT)
X-Sender: davej@neo.local
To:     "'kernel-audit@nl.linux.org'" <kernel-audit@nl.linux.org>
cc:     engler@csl.stanford.edu
Subject: RE: encrypting swap conversation
In-Reply-To: <4B3EBD3B46D7D21194B30008C7B1C76505795886@OLTEX134>
Message-ID: <Pine.LNX.4.21.0008081932190.5900-100000@neo.local>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Tue, 8 Aug 2000, Copeland, Matthew wrote:

> Just a thought, everyone might want to go through the lkml archives and read
> the recent thread on Crypto, since essentially this is entirely being
> rehashed right here.  :)

And people seem to be forgetting the principle that a code AUDIT
does not mean the same thing as "lets add this feature, it'll be more
secure".

In an attempt to steer things back towards the real objective,
a few postings to linux kernel in the last few days have been
made regarding g++ extensions to check things like..

- calls to sleep functions before MOD_INC
- calls to sleep functions after MOD_DEC
- returns with error after MOD_INC should MOD_DEC
- Variables >512 bytes
- Unmatched spin_unlocks() after spin_lock()

If other people on the list can come up with a series of other tests,
this could make for a good 'audit-suite'.

regards,

-- 
Dave.


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 20:53:40 2000
Received: by humbolt.nl.linux.org id <S92353AbQHHSvW>;
	Tue, 8 Aug 2000 20:51:22 +0200
Received: from [206.96.185.76] ([206.96.185.76]:59148 "EHLO fury.localdomain")
	by humbolt.nl.linux.org with ESMTP id <S92345AbQHHSu0>;
	Tue, 8 Aug 2000 20:50:26 +0200
Received: from localhost (sjp@localhost)
	by fury.localdomain (8.9.3/8.9.3) with ESMTP id KAA28587;
	Tue, 8 Aug 2000 10:41:42 -0700
X-Authentication-Warning: fury.localdomain: sjp owned process doing -bs
Date:   Tue, 8 Aug 2000 10:41:42 -0700 (PDT)
From:   Pollei <sjp@toolbuilders.com>
X-Sender: sjp@fury.localdomain
To:     James Stevenson <mistral@stevenson.zetnet.co.uk>
cc:     "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>,
        kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
In-Reply-To: <Pine.LNX.4.21.0008071439450.20543-100000@linux.home>
Message-ID: <Pine.LNX.4.10.10008081019090.28442-100000@fury.localdomain>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, James Stevenson wrote:

> 
> Hi
> 
> one of the things that i though was what is the point in encrypting the
> swap file under linux i do not see any benifits
> it would be slower
> no added security (/proc/kcore ?) unless the person who set the system
> up has left the swap world readable (duh) if you are root you can just
> poke around the processes memory anyway
It is mostly for things like passwds or temporarily unencrypted info that
is stored in memory. Perhaps one could argue that one needs to identify
all that info and use mlock, mlockall, and friends to prevent it from
swapping.
Otherwise things that you thought are temporary might become more
permanent... Things like your private key that was protected by a
passphrase being written in clear-text out to swap.
First rule on these temporary intermediates is to memset(buf,0,cnt) them
when done.
Second rule is to lock them down so they don't swap and/or encrypt the
swap.

Which one is more expensive performance
wise mlockall(MCL_CURRENT|MCL_FUTURE) or encrypted swap?
Which one is easier to audit and make sure you caught all the cases?
I think that especially with all the gui stuff that people are trying to
use that an encrypted swap would be much easier to verify correctness of.
Besides if you are really concerned about performance you shouldn't be
swapping that much if any anyway.


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 21:31:40 2000
Received: by humbolt.nl.linux.org id <S92354AbQHHTaS>;
	Tue, 8 Aug 2000 21:30:18 +0200
Received: from terra.geo.uu.nl ([131.211.29.16]:21634 "EHLO terra.geo.uu.nl")
	by humbolt.nl.linux.org with ESMTP id <S92345AbQHHT3y>;
	Tue, 8 Aug 2000 21:29:54 +0200
Received: from nifty.Blue-Labs.org (root@nifty.blue-labs.org [208.179.0.193])
	by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id VAA15976
	for <kernel-audit@nl.linux.org>; Tue, 8 Aug 2000 21:29:51 +0200 (MET DST)
Received: from kalifornia.com (david@localhost [127.0.0.1])
	by nifty.Blue-Labs.org (8.11.0/8.11.0) with ESMTP id e78JSiv10133;
	Tue, 8 Aug 2000 12:28:45 -0700
Message-ID: <39905F6C.2506A9F1@kalifornia.com>
Date:   Tue, 08 Aug 2000 12:28:44 -0700
From:   David Ford <david@kalifornia.com>
Organization: Talon Technology, Intl.
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.4.0-test6 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     root <root@quasisoft.com>
CC:     kernel-audit@nl.linux.org
Subject: Re: TEST
References: <20000807041118.714D74333B4@mail.quasisoft.com>
Content-Type: multipart/mixed;
 boundary="------------5190325BB3048A2186E94855"
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

This is a multi-part message in MIME format.
--------------5190325BB3048A2186E94855
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

...added to twit filters.

-d

root wrote:

> Stop blocking me.
>
> Kernel-audit:  discussion list for security and the linux kernel
> Archive:       http://mail.nl.linux.org/kernel-audit/

--
"The difference between 'involvement' and 'commitment' is like an
eggs-and-ham breakfast: the chicken was 'involved' - the pig was
'committed'."



--------------5190325BB3048A2186E94855
Content-Type: text/x-vcard; charset=us-ascii;
 name="david.vcf"
Content-Transfer-Encoding: 7bit
Content-Description: Card for David Ford
Content-Disposition: attachment;
 filename="david.vcf"

begin:vcard 
n:Ford;David
x-mozilla-html:TRUE
org:<img src="http://www.kalifornia.com/images/paradise.jpg">
adr:;;;;;;
version:2.1
email;internet:david@kalifornia.com
title:Blue Labs Developer
x-mozilla-cpt:;-12480
fn:David Ford
end:vcard

--------------5190325BB3048A2186E94855--


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 22:12:29 2000
Received: by humbolt.nl.linux.org id <S92355AbQHHUK6>;
	Tue, 8 Aug 2000 22:10:58 +0200
Received: from brutus.conectiva.com.br ([200.250.58.146]:56047 "EHLO
        duckman.distro.conectiva") by humbolt.nl.linux.org with ESMTP
	id <S92359AbQHHUK3>; Tue, 8 Aug 2000 22:10:29 +0200
Received: from localhost (riel@localhost)
	by duckman.distro.conectiva (8.9.3/8.8.7) with ESMTP id RAA09846;
	Tue, 8 Aug 2000 17:09:59 -0300
X-Authentication-Warning: duckman.distro.conectiva: riel owned process doing -bs
Date:   Tue, 8 Aug 2000 17:09:59 -0300 (BRST)
From:   Rik van Riel <riel@conectiva.com.br>
X-Sender: riel@duckman.distro.conectiva
To:     root <root@quasisoft.com>
cc:     kernel-audit@nl.linux.org
Subject: Re: TEST
In-Reply-To: <20000807041103.79CD64333B3@mail.quasisoft.com>
Message-ID: <Pine.LNX.4.21.0008081708530.5200-100000@duckman.distro.conectiva>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Sun, 6 Aug 2000, root wrote:

> Stop blocking me.

All your emails arrived at the mailing list just fine.
You're not blocked, but consider this your last warning.

(follow-ups by private email please, I think the list
has had enough now)

regards,

Rik
--
"What you're running that piece of shit Gnome?!?!"
       -- Miguel de Icaza, UKUUG 2000

http://www.conectiva.com/		http://www.surriel.com/



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 22:19:41 2000
Received: by humbolt.nl.linux.org id <S92364AbQHHUSW>;
	Tue, 8 Aug 2000 22:18:22 +0200
Received: from [63.226.207.58] ([63.226.207.58]:33289 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92359AbQHHURl>;
	Tue, 8 Aug 2000 22:17:41 +0200
Received: by mail.quasisoft.com (Postfix, from userid 504)
	id E869A433397; Tue,  8 Aug 2000 13:22:12 -0700 (PDT)
Date:   Tue, 8 Aug 2000 13:22:12 -0700
From:   quasi@quasisoft.com
To:     David Ford <david@kalifornia.com>
Cc:     kernel-audit@nl.linux.org
Subject: Re: TEST
Message-ID: <20000808132212.A3465@quasisoft.com>
References: <20000807041118.714D74333B4@mail.quasisoft.com> <39905F6C.2506A9F1@kalifornia.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <39905F6C.2506A9F1@kalifornia.com>; from david@kalifornia.com on Tue, Aug 08, 2000 at 12:28:44PM -0700
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Added postfix to the trash bin.

On Tue, Aug 08, 2000 at 12:28:44PM -0700, David Ford wrote:
> ...added to twit filters.
> 
> -d
> 
> root wrote:
> 
> > Stop blocking me.
> >

-- 

http://www.quasisoft.com

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Tue Aug  8 22:52:30 2000
Received: by humbolt.nl.linux.org id <S92361AbQHHUvK>;
	Tue, 8 Aug 2000 22:51:10 +0200
Received: from [63.226.207.58] ([63.226.207.58]:34057 "EHLO mail.quasisoft.com")
	by humbolt.nl.linux.org with ESMTP id <S92359AbQHHUuu>;
	Tue, 8 Aug 2000 22:50:50 +0200
Received: by mail.quasisoft.com (Postfix, from userid 504)
	id 33F2E433397; Tue,  8 Aug 2000 13:55:18 -0700 (PDT)
Date:   Tue, 8 Aug 2000 13:55:18 -0700
From:   quasi@quasisoft.com
To:     kernel-audit@nl.linux.org
Subject: Re: TEST
Message-ID: <20000808135518.A3529@quasisoft.com>
References: <20000807041118.714D74333B4@mail.quasisoft.com> <39905F6C.2506A9F1@kalifornia.com> <20000808132212.A3465@quasisoft.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.4i
In-Reply-To: <20000808132212.A3465@quasisoft.com>; from quasi@quasisoft.com on Tue, Aug 08, 2000 at 01:22:12PM -0700
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Wonder if this has anything to do with buffer overflows, stack frame
over-writes or ipchains pitfalls.

> Added postfix to the trash bin.
> 
> > ...added to twit filters.
> > 
> > root wrote:
> > 
> > > Stop blocking me.

-- 

http://www.quasisoft.com

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Wed Aug  9 17:58:09 2000
Received: by humbolt.nl.linux.org id <S92377AbQHIP4s>;
	Wed, 9 Aug 2000 17:56:48 +0200
Received: from serenity.mcc.ac.uk ([130.88.200.93]:63504 "EHLO
        serenity.mcc.ac.uk") by humbolt.nl.linux.org with ESMTP
	id <S92375AbQHIP4K>; Wed, 9 Aug 2000 17:56:10 +0200
Received: from mrbounce.compsoc.man.ac.uk ([192.84.78.5])
	by serenity.mcc.ac.uk with esmtp (Exim 2.05 #4)
	id 13MYDB-00060b-00; Wed, 9 Aug 2000 16:56:09 +0100
Received: from mrbusy.compsoc.man.ac.uk (root@mrbusy.compsoc.man.ac.uk [192.84.78.3])
	by mrbounce.compsoc.man.ac.uk (8.9.2/8.9.2) with ESMTP id QAA22527;
	Wed, 9 Aug 2000 16:56:09 +0100 (BST)
	(envelope-from moz@compsoc.man.ac.uk)
Received: from localhost (moz@localhost)
	by mrbusy.compsoc.man.ac.uk (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA14143;
	Wed, 9 Aug 2000 16:56:08 +0100
X-Authentication-Warning: mrbusy.compsoc.man.ac.uk: moz owned process doing -bs
Date:   Wed, 9 Aug 2000 16:56:08 +0100 (GMT)
From:   John Levon <moz@compsoc.man.ac.uk>
To:     davej@suse.de
cc:     "'kernel-audit@nl.linux.org'" <kernel-audit@nl.linux.org>
Subject: RE: encrypting swap conversation
In-Reply-To: <Pine.LNX.4.21.0008081932190.5900-100000@neo.local>
Message-ID: <Pine.LNX.4.21.0008091652540.13768-100000@mrbusy.compsoc.man.ac.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Tue, 8 Aug 2000 davej@suse.de wrote:

> On Tue, 8 Aug 2000, Copeland, Matthew wrote:
> 
> > Just a thought, everyone might want to go through the lkml archives and read
> > the recent thread on Crypto, since essentially this is entirely being
> > rehashed right here.  :)
> 
> And people seem to be forgetting the principle that a code AUDIT
> does not mean the same thing as "lets add this feature, it'll be more
> secure".
> 
> In an attempt to steer things back towards the real objective,
> a few postings to linux kernel in the last few days have been
> made regarding g++ extensions to check things like..
> 
> - calls to sleep functions before MOD_INC
> - calls to sleep functions after MOD_DEC
> - returns with error after MOD_INC should MOD_DEC
> - Variables >512 bytes
> - Unmatched spin_unlocks() after spin_lock()
> 
> If other people on the list can come up with a series of other tests,
> this could make for a good 'audit-suite'.
> 
> regards,
> 
>

Dave, you took the words right out of my mouth :)

I've only just joined this list, so I wasn't sure whether some one had
actually started one of these, but imho a "checklist" would be very
useful. It's not substitute for a proper audit by experienced hackers, but
there is a dearth of experienced hackers willing to do this :)

at the very least it would help catch things like the above, but stuff
that a gcc extension can't find

so does anyone want to start a checklist ?

john

p.s. dave how come your name is your sig ? it looks odd as above :)

p.p.s. someone suggested including an offset in the pci mmio space
functions to catch naughty drivers, as they do on mips. has anyone looked
at this ?



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Wed Aug 16 23:53:08 2000
Received: by humbolt.nl.linux.org id <S92573AbQHPVvc>;
	Wed, 16 Aug 2000 23:51:32 +0200
Received: from asterix.hrz.tu-chemnitz.de ([134.109.132.84]:50685 "EHLO
        asterix.hrz.tu-chemnitz.de") by humbolt.nl.linux.org with ESMTP
	id <S92546AbQHPVut>; Wed, 16 Aug 2000 23:50:49 +0200
Received: from mykonos.informatik.tu-chemnitz.de by asterix.hrz.tu-chemnitz.de 
          with Local SMTP (PP); Wed, 16 Aug 2000 23:50:42 +0200
Received: from sparta.informatik.tu-chemnitz.de (sparta.informatik.tu-chemnitz.de [134.109.192.160]) 
          by mykonos.informatik.tu-chemnitz.de (8.8.8+Sun/8.8.8) with ESMTP 
          id XAA01779; Wed, 16 Aug 2000 23:50:33 +0200 (MET DST)
Date:   Wed, 16 Aug 2000 23:50:33 +0200 (MET DST)
From:   Alexander Schreiber 
        <Alexander.Schreiber@Informatik.TU-Chemnitz.DE>
To:     James Stevenson <mistral@stevenson.zetnet.co.uk>
cc:     "Mr. Shannon Aldinger" <god@yinyang.hjsoft.com>,
        kernel-audit@nl.linux.org
Subject: Re: encrypting swap (was Re: TEST)
In-Reply-To: <Pine.LNX.4.21.0008071439450.20543-100000@linux.home>
Message-ID: <Pine.GSO.4.21.0008161900070.19011-100000@sparta.informatik.tu-chemnitz.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Mon, 7 Aug 2000, James Stevenson wrote:

> 
> Hi
> 
> one of the things that i though was what is the point in encrypting the
> swap file under linux i do not see any benifits
> it would be slower
> no added security (/proc/kcore ?) unless the person who set the system
> up has left the swap world readable (duh) if you are root you can just
> poke around the processes memory anyway

The idea is not to protect you from someone gaining access as root to the
_running_ machine. Rather the scenario is as follows:

- you have a machine with sensitive data - a laptop for instance
- whenever the machine is running, it is sufficiently secure from 
  direct unauthorized access (because it is locked down real tight ->
  no unauthorized remote root access, you are sitting in front of it
  -> no unauthorized console acces),
- what happens if someone gains physical access to the machine after you
  turned it off - for instance it gets stolen?
  - attacker has physical access, so he can do _everything_ to the system
    to get at your data
  - all filesystems are encrypted, so no way to access them
  - _but_ the swap is normally wide open and very likely contains some
    sensitive data (paged out pages from processes handling said data),
    maybe even the password to access the filesysystems
 
This is where encrypted swap comes in: without the key, even the swapspace
contains only garbage. The key is generated new at each boot (with enough
random in it, maybe by doing an md5sum of ps -auxwww, and then throwing away
the key. This way the swap cannot be decrypted after reboot.

Regards,
        Alex.
-- 
------------------------------------------------------------------------------ 
 EMail : als@thangorodrim.de              | WWW : http://www.thangorodrim.de/
 "I think there's a world market for about five computers."
         -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 17 10:20:16 2000
Received: by humbolt.nl.linux.org id <S92528AbQHQIRZ>;
	Thu, 17 Aug 2000 10:17:25 +0200
Received: from gwa2.fe.bosch.de ([194.39.218.2]:44934 "EHLO gwa2.fe.bosch.de")
	by humbolt.nl.linux.org with ESMTP id <S92476AbQHQIQW>;
	Thu, 17 Aug 2000 10:16:22 +0200
Received: (from uucp@localhost)
	by gwa2.fe.bosch.de (8.9.1/8.9.1) id IAA05559
	for <kernel-audit@nl.linux.org>; Thu, 17 Aug 2000 08:16:14 GMT
Received: from fez8019.fe.bosch.de(virus-out.fe.internet.bosch.de 10.4.4.19) by gwa2.fe.bosch.de via smap (V2.1)
	id xma004836; Thu, 17 Aug 00 08:15:31 GMT
Received: by fez7202.server.bosch.de with Internet Mail Service (5.5.2651.58)
	id <RCC0DY07>; Thu, 17 Aug 2000 10:15:26 +0200
Message-ID: <4BA83203985FD411A34A00508B69D83107F0EE@frmail3.fr.bosch.de>
From:   "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
To:     "'Alexander Schreiber'" 
        <Alexander.Schreiber@Informatik.TU-Chemnitz.DE>
Cc:     kernel-audit@nl.linux.org
Subject: RE: encrypting swap
Date:   Thu, 17 Aug 2000 10:15:20 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

> From: Alexander Schreiber
>
> The idea is not to protect you from someone gaining access as 
> root to the
> _running_ machine. Rather the scenario is as follows:
> 
> - you have a machine with sensitive data - a laptop for instance
> - whenever the machine is running, it is sufficiently secure from 
>   direct unauthorized access (because it is locked down real tight ->
>   no unauthorized remote root access, you are sitting in front of it
>   -> no unauthorized console acces),
> - what happens if someone gains physical access to the 
> machine after you
>   turned it off - for instance it gets stolen?
>   - attacker has physical access, so he can do _everything_ 
> to the system
>     to get at your data
>   - all filesystems are encrypted, so no way to access them
>   - _but_ the swap is normally wide open and very likely contains some
>     sensitive data (paged out pages from processes handling 
> said data),
>     maybe even the password to access the filesysystems
>  
> This is where encrypted swap comes in: without the key, even 
> the swapspace
> contains only garbage. The key is generated new at each boot 
> (with enough
> random in it, maybe by doing an md5sum of ps -auxwww, and 
> then throwing away
> the key. This way the swap cannot be decrypted after reboot.

Stay with your laptop example. 

1) You switch the laptop completely off (no suspend to disk!). Then 
there may remain sensitive data on the swap partition.
Solution: Just overwrite the swap partition with zeroes on shutdown:
	swapoff, then dd in=/dev/null out=/dev/hda<whatever> ...
You could even go more sophisticated by changing sys_swapoff() in such a
way that when unregistering a swap partition, the kernel goes through the
swap partition's swap_map[] and just overwrites the swap pages that were
actually in use. Then, the swapoff would clean the swap partition 
automatically.
2) You go to a suspend state. Then you also should erase the swap
partition, but now before going to suspend. This may be more complicated
than in the first case. 
2.1) If you use a method like swsusp, i.e. going to suspend
under control of Linux, then you can umount and clean the swap prior to
switching to suspend. 
2.2) If you use the Laptop-BIOS to go to suspend, then you
have a problem because (as far as I know) there are no hooks to register
some routine doing the swap cleaning.

I don't like very much the idea of an encrypted swap because of the large 
performance penalty you're going to suffer.

Regards,
Thomas.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 17 10:55:36 2000
Received: by humbolt.nl.linux.org id <S92576AbQHQIwC>;
	Thu, 17 Aug 2000 10:52:02 +0200
Received: from sirppi.helsinki.fi ([128.214.205.27]:55054 "EHLO
        sirppi.helsinki.fi") by humbolt.nl.linux.org with ESMTP
	id <S92438AbQHQIuv>; Thu, 17 Aug 2000 10:50:51 +0200
Received: from localhost (ammonton@localhost)
	by sirppi.helsinki.fi (8.10.1/8.10.1) with ESMTP id e7H8oBw06768;
	Thu, 17 Aug 2000 11:50:12 +0300 (EET DST)
X-Authentication-Warning: sirppi.helsinki.fi: ammonton owned process doing -bs
Date:   Thu, 17 Aug 2000 11:50:11 +0300 (EET DST)
From:   Anders M Montonen <ammonton@cc.helsinki.fi>
To:     "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
cc:     kernel-audit@nl.linux.org
Subject: RE: encrypting swap
In-Reply-To: <4BA83203985FD411A34A00508B69D83107F0EE@frmail3.fr.bosch.de>
Message-ID: <Pine.OSF.4.20.0008171142210.1162-100000@sirppi.helsinki.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Thu, 17 Aug 2000, Strohm Thomas (FV/SLD) * wrote:

> 1) You switch the laptop completely off (no suspend to disk!). Then 
> there may remain sensitive data on the swap partition.
> Solution: Just overwrite the swap partition with zeroes on shutdown:
> 	swapoff, then dd in=/dev/null out=/dev/hda<whatever> ...

The problem with this method is that with suitable equipment, reading a
drive wiped in this way is pretty easy. A better way would be to write
random data over the drive, but to be sure you have to do it several times
(I believe there is an american directive regarding this that requires you
to write random data six times). This is time-consuming and even then 
might not be completely safe.
 On the other hand, encrypting the swap ensures that whatever data can be
read is useless. Yes, there is a performance hit, but if you need this
level of security it is the price you have to pay.

-anders


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 17 11:02:43 2000
Received: by humbolt.nl.linux.org id <S92595AbQHQI7O>;
	Thu, 17 Aug 2000 10:59:14 +0200
Received: from gwa2.fe.bosch.de ([194.39.218.2]:35022 "EHLO gwa2.fe.bosch.de")
	by humbolt.nl.linux.org with ESMTP id <S92478AbQHQI5v>;
	Thu, 17 Aug 2000 10:57:51 +0200
Received: (from uucp@localhost)
	by gwa2.fe.bosch.de (8.9.1/8.9.1) id IAA11516
	for <kernel-audit@nl.linux.org>; Thu, 17 Aug 2000 08:57:48 GMT
Received: from fez8020.fe.bosch.de(virus-out2.fe.internet.bosch.de 10.4.4.20) by gwa2.fe.bosch.de via smap (V2.1)
	id xma010799; Thu, 17 Aug 00 08:57:22 GMT
Received: by fez7202.server.bosch.de with Internet Mail Service (5.5.2651.58)
	id <RCC0D58T>; Thu, 17 Aug 2000 10:57:17 +0200
Message-ID: <4BA83203985FD411A34A00508B69D83107F0EF@frmail3.fr.bosch.de>
From:   "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
To:     "'Anders M Montonen'" <ammonton@cc.helsinki.fi>
Cc:     kernel-audit@nl.linux.org
Subject: RE: encrypting swap
Date:   Thu, 17 Aug 2000 10:57:11 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

> The problem with this method is that with suitable equipment, 
> reading a drive wiped in this way is pretty easy.

Oops. Sounds interesting, but kind of disturbing as well. I can
only guess. If you perform the magnetisation representing the zero 
(say), is there still a remainder of the old magnetisation (kind of
corona around the new bit) that can be detected?

Thomas.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 17 11:13:35 2000
Received: by humbolt.nl.linux.org id <S92625AbQHQJLF>;
	Thu, 17 Aug 2000 11:11:05 +0200
Received: from sirppi.helsinki.fi ([128.214.205.27]:34578 "EHLO
        sirppi.helsinki.fi") by humbolt.nl.linux.org with ESMTP
	id <S92631AbQHQJJ7>; Thu, 17 Aug 2000 11:09:59 +0200
Received: from localhost (ammonton@localhost)
	by sirppi.helsinki.fi (8.10.1/8.10.1) with ESMTP id e7H99vx05365;
	Thu, 17 Aug 2000 12:09:57 +0300 (EET DST)
X-Authentication-Warning: sirppi.helsinki.fi: ammonton owned process doing -bs
Date:   Thu, 17 Aug 2000 12:09:57 +0300 (EET DST)
From:   Anders M Montonen <ammonton@cc.helsinki.fi>
To:     "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
cc:     kernel-audit@nl.linux.org
Subject: RE: encrypting swap
In-Reply-To: <4BA83203985FD411A34A00508B69D83107F0EF@frmail3.fr.bosch.de>
Message-ID: <Pine.OSF.4.20.0008171200470.1162-100000@sirppi.helsinki.fi>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Thu, 17 Aug 2000, Strohm Thomas (FV/SLD) * wrote:

> > The problem with this method is that with suitable equipment, 
> > reading a drive wiped in this way is pretty easy.
> Oops. Sounds interesting, but kind of disturbing as well. I can
> only guess. If you perform the magnetisation representing the zero 
> (say), is there still a remainder of the old magnetisation (kind of
> corona around the new bit) that can be detected?

That, and the fact that the R/W head doesn't pass *exactly* over the old
track when writing, leaves enough of a trace to read the old data. There
are companies providing this type of service, eg. www.ibas.no. It is
extremely expensive, but if your harddrive containing vital information
burned up in a fire, chances are they can still read it.

-anders



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 17 12:58:05 2000
Received: by humbolt.nl.linux.org id <S92575AbQHQKzr>;
	Thu, 17 Aug 2000 12:55:47 +0200
Received: from lemuria.borgfelde.ricardo.de ([195.244.103.65]:40967 "EHLO
        mail.lemuria.org") by humbolt.nl.linux.org with ESMTP
	id <S92613AbQHQKyz>; Thu, 17 Aug 2000 12:54:55 +0200
Received: by mail.lemuria.org (Postfix, from userid 500)
	id 68C9427AB4; Thu, 17 Aug 2000 12:53:07 +0200 (MEST)
Date:   Thu, 17 Aug 2000 12:53:07 +0200
From:   Tom Vogt <tom@lemuria.org>
To:     kernel-audit@nl.linux.org
Subject: encrypting swap
Message-ID: <20000817125307.A9688@lemuria.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
X-Privacy: If you can, please encrypt your mails - finger for key
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


"Strohm Thomas (FV/SLD) * wrote:
> Oops. Sounds interesting, but kind of disturbing as well. I can
> only guess. If you perform the magnetisation representing the zero
> (say), is there still a remainder of the old magnetisation (kind of
> corona around the new bit) that can be detected?

yes. residual magnetism survives several overwrites.

also, you have to take into account that a binary 0 you send to the
drive will NOT usually result in a 0 written to the magnetic layer.
drives make some translation for the purposes of error correction and
equal distribution of magnetism across the magnetic layer (you wouldn't
want half of the disk positive and the other half negative because you
wrote the right pattern of 0s and 1s...)



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 17 17:09:02 2000
Received: by humbolt.nl.linux.org id <S92346AbQHQPH2>;
	Thu, 17 Aug 2000 17:07:28 +0200
Received: from lemuria.borgfelde.ricardo.de ([195.244.103.65]:60686 "HELO
        mail.lemuria.org") by humbolt.nl.linux.org with SMTP
	id <S92643AbQHQPGp>; Thu, 17 Aug 2000 17:06:45 +0200
Received: from lemuria.org by mail.lemuria.org
	via rsmtp with bsmtp
	id <m13PRDu-0015wGC@mail.lemuria.org>
	for <kernel-audit@nl.linux.org>; Thu, 17 Aug 2000 17:04:50 +0200 (MEST)
	(Smail-3.2 1996-Jul-4 #1 built 1999-Nov-8)
Received: by lemuria.org
	via sendmail with stdio
	id <m13PQtl-000HfPC@lemuria.org>
	for kernel-audit@nl.linux.org; Thu, 17 Aug 2000 16:44:01 +0200 (MEST)
	(Smail-3.2 1996-Jul-4 #1 built 1999-Nov-8)
Date:   Thu, 17 Aug 2000 16:44:01 +0200
From:   Tom Vogt <tom@lemuria.org>
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
Message-ID: <20000817164401.A5295@lemuria.org>
References: <4BA83203985FD411A34A00508B69D83107F0EE@frmail3.fr.bosch.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <4BA83203985FD411A34A00508B69D83107F0EE@frmail3.fr.bosch.de>
X-Privacy: If you can, please encrypt your mails - finger for key
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

"Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com> wrote:
> I don't like very much the idea of an encrypted swap because of the large 
> performance penalty you're going to suffer.

unfortunately, there are many scenarios where "let's wipe the swap" doesn't
cut it. example: the evil guys storm your house and take the machine. the
power is gone, but it's not been through a shutdown procedure and you had
no chance to wipe anything.

*if* you are paranoid enough to be afraid of your own swap, you've got to
think about the worst-case scenarios. the example above and the residual
magnetism problem make anything but encryption not-good-enough.

-- 
"The net treats censorship as a malfunction and re-routes around it."
(John Gilmore)

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 17 18:27:47 2000
Received: by humbolt.nl.linux.org id <S92588AbQHQQ0W>;
	Thu, 17 Aug 2000 18:26:22 +0200
Received: from obelix.hrz.tu-chemnitz.de ([134.109.132.55]:22965 "EHLO
        obelix.hrz.tu-chemnitz.de") by humbolt.nl.linux.org with ESMTP
	id <S92443AbQHQQZl>; Thu, 17 Aug 2000 18:25:41 +0200
Received: from mykonos.informatik.tu-chemnitz.de by obelix.hrz.tu-chemnitz.de 
          with Local SMTP (PP); Thu, 17 Aug 2000 18:25:09 +0200
Received: from sparta.informatik.tu-chemnitz.de (sparta.informatik.tu-chemnitz.de [134.109.192.160]) 
          by mykonos.informatik.tu-chemnitz.de (8.8.8+Sun/8.8.8) with ESMTP 
          id SAA24168; Thu, 17 Aug 2000 18:25:07 +0200 (MET DST)
Date:   Thu, 17 Aug 2000 18:24:56 +0200 (MET DST)
From:   Alexander Schreiber 
        <Alexander.Schreiber@Informatik.TU-Chemnitz.DE>
To:     "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
cc:     'Alexander Schreiber' 
        <Alexander.Schreiber@Informatik.TU-Chemnitz.DE>,
        kernel-audit@nl.linux.org
Subject: RE: encrypting swap
In-Reply-To: <4BA83203985FD411A34A00508B69D83107F0EE@frmail3.fr.bosch.de>
Message-ID: <Pine.GSO.4.21.0008171817560.14585-100000@sparta.informatik.tu-chemnitz.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Hi !

On Thu, 17 Aug 2000, Strohm Thomas (FV/SLD) * wrote:

> > From: Alexander Schreiber
> >
> > The idea is not to protect you from someone gaining access as 
> > root to the
> > _running_ machine. Rather the scenario is as follows:
> > 
> > - you have a machine with sensitive data - a laptop for instance
> > - whenever the machine is running, it is sufficiently secure from 
> >   direct unauthorized access (because it is locked down real tight ->
> >   no unauthorized remote root access, you are sitting in front of it
> >   -> no unauthorized console acces),
> > - what happens if someone gains physical access to the 
> > machine after you
> >   turned it off - for instance it gets stolen?
> >   - attacker has physical access, so he can do _everything_ 
> > to the system
> >     to get at your data
> >   - all filesystems are encrypted, so no way to access them
> >   - _but_ the swap is normally wide open and very likely contains some
> >     sensitive data (paged out pages from processes handling 
> > said data),
> >     maybe even the password to access the filesysystems
> >  
> > This is where encrypted swap comes in: without the key, even 
> > the swapspace
> > contains only garbage. The key is generated new at each boot 
> > (with enough
> > random in it, maybe by doing an md5sum of ps -auxwww, and 
> > then throwing away
> > the key. This way the swap cannot be decrypted after reboot.

> Stay with your laptop example. 

> 1) You switch the laptop completely off (no suspend to disk!). Then 
> there may remain sensitive data on the swap partition.
> Solution: Just overwrite the swap partition with zeroes on shutdown:

Ok - but what if the is not shutdown clean (like your batteries running
out on you)?

> 2) You go to a suspend state. Then you also should erase the swap
> partition, but now before going to suspend. This may be more complicated
> than in the first case. 

This ranges from easy (no swap used) to difficult (swap used) to impossible
(used address space > RAM, swap _needed_ for operation of system) - at least
if you don't want to seriously disrupt operation (by forcibly disabling
swap, thereby creating an OOM-situation which will kill processes).

> 2.1) If you use a method like swsusp, i.e. going to suspend
> under control of Linux, then you can umount and clean the swap prior to
> switching to suspend. 

Same problem.

> 2.2) If you use the Laptop-BIOS to go to suspend, then you
> have a problem because (as far as I know) there are no hooks to register
> some routine doing the swap cleaning.

> I don't like very much the idea of an encrypted swap because of the large 
> performance penalty you're going to suffer.

You already get a performance penalty when using unencrypted swap. I hate
to break it to you - but high performance and high security tend to come
in different packages. You have to decide wether you want a secure system
or a fast system. And btw - Blowfish isn't _that_ slow.

Regards,
       Alex.
-- 
------------------------------------------------------------------------------ 
 EMail : als@thangorodrim.de              | WWW : http://www.thangorodrim.de/
 "I think there's a world market for about five computers."
         -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 18 05:32:17 2000
Received: by humbolt.nl.linux.org id <S92220AbQHRDaZ>;
	Fri, 18 Aug 2000 05:30:25 +0200
Received: from terra.geo.uu.nl ([131.211.29.16]:30939 "EHLO terra.geo.uu.nl")
	by humbolt.nl.linux.org with ESMTP id <S92167AbQHRDaC>;
	Fri, 18 Aug 2000 05:30:02 +0200
Received: from localhost.gumbynet.org (root@localhost.gumbynet.org [203.42.225.1])
	by terra.geo.uu.nl (8.9.3/8.9.3/TvZ) with ESMTP id FAA04995
	for <kernel-audit@nl.linux.org>; Fri, 18 Aug 2000 05:29:57 +0200 (MET DST)
Received: from box3n.gumbynet.org (box3n.gumbynet.org [203.43.214.254])
	by localhost.gumbynet.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id NAA30248
	for <kernel-audit@nl.linux.org>; Fri, 18 Aug 2000 13:29:35 +1000
Received: from localhost (fyre@localhost)
	by box3n.gumbynet.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA30305
	for <kernel-audit@nl.linux.org>; Fri, 18 Aug 2000 13:29:45 +1000
Date:   Fri, 18 Aug 2000 13:29:44 +1000 (EST)
From:   Tim Robbins <fyre@box3n.gumbynet.org>
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
In-Reply-To: <20000817164401.A5295@lemuria.org>
Message-ID: <Pine.LNX.4.21.0008181323001.30289-100000@box3n.gumbynet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Just my thoughts on this...

Use mlock() and munlock() to stop the memory getting paged to disk. It's
much harder (impossible?) to retrieve data from memory after it's been
zeroed or after the machine has been turned off. 

Quite a few programs do something similar to this but I can't think of any
examples right now. Since mlock and friends are not portable, I've seen
some programs just memset the sensitive data to zero.

I think encrypting swap would be hard to do quickly and securely - compare
copying a file across a network using scp to using ftp. On low end
hardware, the ftp transfer can go 10-20 times faster.

Tim


--
Tim Robbins
fyre@box3n.gumbynet.org



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 18 09:39:12 2000
Received: by humbolt.nl.linux.org id <S92251AbQHRHhm>;
	Fri, 18 Aug 2000 09:37:42 +0200
Received: from lemuria.borgfelde.ricardo.de ([195.244.103.65]:65039 "HELO
        mail.lemuria.org") by humbolt.nl.linux.org with SMTP
	id <S92167AbQHRHhK>; Fri, 18 Aug 2000 09:37:10 +0200
Received: from lemuria.org by mail.lemuria.org
	via rsmtp with bsmtp
	id <m13Pgcs-0015wMC@mail.lemuria.org>
	for <kernel-audit@nl.linux.org>; Fri, 18 Aug 2000 09:31:38 +0200 (MEST)
	(Smail-3.2 1996-Jul-4 #1 built 1999-Nov-8)
Received: by lemuria.org
	via sendmail with stdio
	id <m13PgPL-000HfHC@lemuria.org>
	for kernel-audit@nl.linux.org; Fri, 18 Aug 2000 09:17:39 +0200 (MEST)
	(Smail-3.2 1996-Jul-4 #1 built 1999-Nov-8)
Date:   Fri, 18 Aug 2000 09:17:39 +0200
From:   Tom Vogt <tom@lemuria.org>
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
Message-ID: <20000818091739.A9056@lemuria.org>
References: <20000817164401.A5295@lemuria.org> <Pine.LNX.4.21.0008181323001.30289-100000@box3n.gumbynet.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailer: Mutt 1.0pre3i
In-Reply-To: <Pine.LNX.4.21.0008181323001.30289-100000@box3n.gumbynet.org>
X-Privacy: If you can, please encrypt your mails - finger for key
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Tim Robbins <fyre@box3n.gumbynet.org> wrote:
> Quite a few programs do something similar to this but I can't think of any
> examples right now.

gpg (if installed suid root, since mlock requires root privs)

> I think encrypting swap would be hard to do quickly and securely - compare
> copying a file across a network using scp to using ftp. On low end
> hardware, the ftp transfer can go 10-20 times faster.

depends. if you use -c blowfish, current hardware (a p3) can satiate a 100
mbit ethernet. I know my old pentium 133 can satiate a 10 mbit ethernet
with blowfish.

-- 
"The net treats censorship as a malfunction and re-routes around it."
(John Gilmore)

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 18 11:41:48 2000
Received: by humbolt.nl.linux.org id <S92324AbQHRJke>;
	Fri, 18 Aug 2000 11:40:34 +0200
Received: from gwa2.fe.bosch.de ([194.39.218.2]:6845 "EHLO gwa2.fe.bosch.de")
	by humbolt.nl.linux.org with ESMTP id <S92256AbQHRJkP>;
	Fri, 18 Aug 2000 11:40:15 +0200
Received: (from uucp@localhost)
	by gwa2.fe.bosch.de (8.9.1/8.9.1) id JAA07664
	for <kernel-audit@nl.linux.org>; Fri, 18 Aug 2000 09:40:14 GMT
Received: from fez8020.fe.bosch.de(virus-out2.fe.internet.bosch.de 10.4.4.20) by gwa2.fe.bosch.de via smap (V2.1)
	id xma007131; Fri, 18 Aug 00 09:39:36 GMT
Received: by fez7202.server.bosch.de with Internet Mail Service (5.5.2651.58)
	id <R117MA20>; Fri, 18 Aug 2000 11:39:17 +0200
Message-ID: <4BA83203985FD411A34A00508B69D83107F0F4@frmail3.fr.bosch.de>
From:   "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
To:     "'Alexander Schreiber'" 
        <Alexander.Schreiber@Informatik.TU-Chemnitz.DE>
Cc:     kernel-audit@nl.linux.org
Subject: RE: encrypting swap
Date:   Fri, 18 Aug 2000 11:39:17 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Alexander Schreiber wrote:

> > 1) You switch the laptop completely off (no suspend to disk!). Then 
> > there may remain sensitive data on the swap partition.
> > Solution: Just overwrite the swap partition with zeroes on shutdown:
> 
> Ok - but what if the is not shutdown clean (like your 
> batteries running out on you)?
> 
> > 2) You go to a suspend state. Then you also should erase the swap
> > partition, but now before going to suspend. This may be 
> > more complicated than in the first case. 
> 
> This ranges from easy (no swap used) to difficult (swap used) 
> to impossible (used address space > RAM, swap _needed_ for operation of 
> system) - at least if you don't want to seriously disrupt operation 
> (by forcibly disabling swap, thereby creating an OOM-situation which 
> will kill processes).

Ok, you're right. I oversaw this.
Then think of the following scenario which works in the cases
(1) You modify the hibernation code in the BIOS.
(2) You use a suspend mechanism in the kernel, like swsusp.

- You do no swap encryption in the normal operation mode of the laptop
- Now you want to suspend the machine
- Stop all processes, swap them out. Now only one kernel 'thread' still
  runs
- This thread copies the contents of the swap partition to a dedicated
  hibernation partition while encrypting it. And also zeros the swap...
- Switch off

- Switch on
- Kernel gets booted
- Kernel restores some in ram things like process list etc. and
  decrypts and copies stuff from hib. part. to swap.
- Normal operation continues.

Advantages:
- No performance penalty whatsoever in normal operation

Disadvantages:
- May take some time when copying and encrypting the swap partition.
- Does not work if you run out of batteries (as you pointed out!)

> > I don't like very much the idea of an encrypted swap 
> > because of the large performance penalty you're going to suffer.

> I hate to break it to you - but high performance and high security 
> tend to come in different packages.

[Thanks for pointing that out :-)]

Sure. But you don't have to accept the first policy that comes into
your mind and attributing its shortcomings to "high performance vs.
high security".

> Blowfish isn't _that_ slow.

Does anyone have numbers? Blowfish C code can be found in Schneiers
book. Is the code available on the internet?

I think the roadmap to estimate the performace loss when using
Blowfish for encrypted swapping could be as follows:

Take a key of a certain length. Then one page corresponds to 512 64-bit
block ciphers, we need the time to encrypt one block times 512. The
resulting number has to be compared to what? I would say to the average
time needed to swap out a page (i.e. 8 disk blocks). Latter depends 
heavily on the load of the machine. If there is almost no load (unlikely
when swapping:-)), then the disk write is committed asynchronously by the
disk drive and you only have to take into consideration the code which
puts the page into the disk's queues() [try_to_swap_out(), 
add_to_swap_cache(), rw_swap_page(), brw_page(), ll_rw_block()]. If the
load is high and the i/o traffic as well, then you'll have to compare the
encryption time to the time needed to write the page (blocks) to disk, 
including seek time etc.

Any comments?

Regards,
Thomas.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 18 14:03:56 2000
Received: by humbolt.nl.linux.org id <S92332AbQHRMCe>;
	Fri, 18 Aug 2000 14:02:34 +0200
Received: from rasputin.xilix.com ([195.139.104.66]:61450 "EHLO
        rasputin.xilix.com") by humbolt.nl.linux.org with ESMTP
	id <S92256AbQHRMCK>; Fri, 18 Aug 2000 14:02:10 +0200
Received: from trustix.com (singsing.trustix.com [195.139.104.158])
	by rasputin.xilix.com (8.9.3/8.9.3) with ESMTP id NAA10355
	for <kernel-audit@nl.linux.org>; Fri, 18 Aug 2000 13:57:34 +0200
Message-ID: <399D25B9.E658F4CB@trustix.com>
Date:   Fri, 18 Aug 2000 14:02:01 +0200
From:   Lars Gaarden <larsg@trustix.com>
Organization: Trustix AS
X-Mailer: Mozilla 4.74 [en] (X11; U; Linux 2.4.0-t6p6imE2 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
References: <4BA83203985FD411A34A00508B69D83107F0F4@frmail3.fr.bosch.de>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

"Strohm Thomas (FV/SLD) *" wrote:
> 
> Alexander Schreiber wrote:

> > > 2) You go to a suspend state. Then you also should erase the swap
> > > partition, but now before going to suspend. This may be
> > > more complicated than in the first case.
> >
> > This ranges from easy (no swap used) to difficult (swap used)
> > to impossible (used address space > RAM, swap _needed_ for operation of
> > system) - at least if you don't want to seriously disrupt operation
> > (by forcibly disabling swap, thereby creating an OOM-situation which
> > will kill processes).
> 
> Ok, you're right. I oversaw this.
> Then think of the following scenario which works in the cases
> (1) You modify the hibernation code in the BIOS.

I don't know how far the OpenBIOS (or was it LinBIOS?) project
has come, but I'd expect that it would be hard to get modified
BIOSes for a sufficient amount of motherboards out there.

> (2) You use a suspend mechanism in the kernel, like swsusp.
> 
> - You do no swap encryption in the normal operation mode of the laptop
> - Now you want to suspend the machine
> - Stop all processes, swap them out. Now only one kernel 'thread' still
>   runs

This will write all keys and passwords currently contained in
application memory to unencrypted swap.

> - This thread copies the contents of the swap partition to a dedicated
>   hibernation partition while encrypting it. And also zeros the swap...

As already mentioned in this thread, just zeroing a part of the disk
does not mean that it is impossible to get back the overwritten data
(www.ibas.no). You'd have to overwrite the swap with random noise
several times to make sure that it is infeasible to get the data back.

> Disadvantages:
> - May take some time when copying and encrypting the swap partition.
> - Does not work if you run out of batteries (as you pointed out!)

- Leaves the swap unencrypted if an attacker is able to crash the
machine.
- Leaves entire userland memory in unencrypted swap if attacker is
able to hang or crash the machine during the hibernation process.

> > I hate to break it to you - but high performance and high security
> > tend to come in different packages.
> 
> [Thanks for pointing that out :-)]
> 
> Sure. But you don't have to accept the first policy that comes into
> your mind and attributing its shortcomings to "high performance vs.
> high security".

Also, functionality and security also tend to come in different
packages. 

-- 
LarsG. These are my opinions, which may or may not be shared by my
employer.
Code that cracks a protection device is criminal under the DMCA even if
the
use of the copyrighted material that the code enables would be fair use.
- Lawrence Lessig, Berkman Professor of Law, Harward Law School.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 18 16:53:25 2000
Received: by humbolt.nl.linux.org id <S92373AbQHROwK>;
	Fri, 18 Aug 2000 16:52:10 +0200
Received: from gwa2.fe.bosch.de ([194.39.218.2]:54174 "EHLO gwa2.fe.bosch.de")
	by humbolt.nl.linux.org with ESMTP id <S92362AbQHROvh>;
	Fri, 18 Aug 2000 16:51:37 +0200
Received: (from uucp@localhost)
	by gwa2.fe.bosch.de (8.9.1/8.9.1) id OAA09348
	for <kernel-audit@nl.linux.org>; Fri, 18 Aug 2000 14:51:34 GMT
Received: from fez8020.fe.bosch.de(virus-out2.fe.internet.bosch.de 10.4.4.20) by gwa2.fe.bosch.de via smap (V2.1)
	id xma009208; Fri, 18 Aug 00 14:50:59 GMT
Received: by fez7202.server.bosch.de with Internet Mail Service (5.5.2651.58)
	id <R117ML92>; Fri, 18 Aug 2000 16:50:53 +0200
Message-ID: <4BA83203985FD411A34A00508B69D83107F0FC@frmail3.fr.bosch.de>
From:   "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
To:     "'Lars Gaarden'" <larsg@trustix.com>
Cc:     kernel-audit@nl.linux.org
Subject: RE: encrypting swap
Date:   Fri, 18 Aug 2000 16:50:50 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

> "Strohm Thomas (FV/SLD) *" wrote:
> > Then think of the following scenario which works in the cases
> > (1) You modify the hibernation code in the BIOS.
> 
> I don't know how far the OpenBIOS (or was it LinBIOS?) project
> has come, but I'd expect that it would be hard to get modified
> BIOSes for a sufficient amount of motherboards out there.

I just added (1) for completeness. OpenBIOS isn't able to do
hibernation (so far?).

> > (2) You use a suspend mechanism in the kernel, like swsusp.
> > 
> > - You do no swap encryption in the normal operation mode of 
> the laptop
> > - Now you want to suspend the machine
> > - Stop all processes, swap them out. Now only one kernel 
> 'thread' still
> >   runs
> 
> This will write all keys and passwords currently contained in
> application memory to unencrypted swap.

Yes, indeed. But these will be deleted in a short while.
 
> > - This thread copies the contents of the swap partition to 
> a dedicated
> >   hibernation partition while encrypting it. And also zeros 
> the swap...
> 
> As already mentioned in this thread, just zeroing a part of the disk
> does not mean that it is impossible to get back the overwritten data
> (www.ibas.no). You'd have to overwrite the swap with random noise
> several times to make sure that it is infeasible to get the data back.

Yes, I remember and got that. Just consider "zero the swap" as a shorthand 
for "write numbers as random as possible many many times to the disk".

> > Disadvantages:
> > - May take some time when copying and encrypting the swap partition.
> > - Does not work if you run out of batteries (as you pointed out!)
> 
> - Leaves the swap unencrypted if an attacker is able to crash the
> machine.
> - Leaves entire userland memory in unencrypted swap if attacker is
> able to hang or crash the machine during the hibernation process.

Yes, I agree.

> > > I hate to break it to you - but high performance and high security
> > > tend to come in different packages.
> > 
> > [Thanks for pointing that out :-)]
> > 
> > Sure. But you don't have to accept the first policy that comes into
> > your mind and attributing its shortcomings to "high performance vs.
> > high security".
> 
> Also, functionality and security also tend to come in different
> packages. 

(Oh, please, convince this big Redmond-located company of that!)

Ok, to summarize: The policy given above does not fulfill the requirement
that **in no moment** there should be sensible plain text data on the
disk. I understand that for security, it is not sufficient to be on the
safe side for 99.999% of the cases but also for the remaining 0.001%. :-)

Fine. 

If you like, I have some further thoughts.

If you use the swap encryption method and like 100% safety w.r.t.
fooling around with the disk, **you can't use the hibernation mode** of your

Most Favorite Laptop (MFL), because it will copy the encryption key (which
is 
most likely located in kernel space) to the hibernation partition. Right?

You could, however, use a swsusp-like suspending facility with an encrypt-
on-suspend plug-in [:-)]. After the suspend, the encryption key gets thrown
away (lack of current in the RAM). You switch on your MFL, it loads the
kernel
and starts to resume. It'll ask you for the key and slurp in the stuff from
disk, decrypting it on-the-fly and thereby restoring the content of the RAM.
Note that the kernel is not written to disk on suspend.

Regards,
Thomas.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 18 21:30:06 2000
Received: by humbolt.nl.linux.org id <S92240AbQHRT3B>;
	Fri, 18 Aug 2000 21:29:01 +0200
Received: from smtp-1.worldonline.cz ([195.146.100.76]:28412 "EHLO
        smtp.worldonline.cz") by humbolt.nl.linux.org with ESMTP
	id <S92190AbQHRT23>; Fri, 18 Aug 2000 21:28:29 +0200
Received: from localhost.localdomain (ppp63.ul.worldonline.cz [212.11.96.65])
	by smtp.worldonline.cz (8.9.3 (WOL 1.2)/8.9.3) with ESMTP id VAA27607
	for <kernel-audit@nl.linux.org>; Fri, 18 Aug 2000 21:27:13 +0200 (MET DST)
Received: by localhost.localdomain (Postfix, from userid 500)
	id 284FF21E3; Fri, 18 Aug 2000 09:37:34 +0200 (CEST)
Date:   Fri, 18 Aug 2000 09:37:34 +0200
From:   Martin Macok <martin.macok@underground.cz>
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
Message-ID: <20000818093734.A1004@localhost>
Mail-Followup-To: kernel-audit@nl.linux.org
References: <4BA83203985FD411A34A00508B69D83107F0EF@frmail3.fr.bosch.de>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="y0ulUmNC+osPPQO6"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <4BA83203985FD411A34A00508B69D83107F0EF@frmail3.fr.bosch.de>; from Thomas.Strohm@de.bosch.com on Thu, Aug 17, 2000 at 10:57:11AM +0200
X-Echelon: NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


--y0ulUmNC+osPPQO6
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Thu, Aug 17, 2000 at 10:57:11AM +0200, Strohm Thomas (FV/SLD) * wrote:
> > The problem with this method is that with suitable equipment, reading
> > a drive wiped in this way is pretty easy.
>=20
> Oops. Sounds interesting, but kind of disturbing as well. I can only
> guess. If you perform the magnetisation representing the zero (say), is
> there still a remainder of the old magnetisation (kind of corona around
> the new bit) that can be detected?

Read the following

      Author: Peter Gutmann
       Title: Secure Deletion of Data from Magnetic and Solid-State Memory
       Pages: 77-89
   Publisher: USENIX
 Proceedings: 6th USENIX Security Symposium
        Date: July 22-25, 1996
    Location: San Jose, CA
 Institution: University of Auckland

You can view it online at http://www.usenix.org/

JFYI:
OpenBSD's "rm -P" overwrites the file three times according to some US
security standard.

Have a nice day

--=20
< Martin Ma=E8ok        martin.macok@underground.cz           <iso-8859-2>=
=20
  \\. http://kocour.ms.mff.cuni.cz/~macok/  http://underground.cz/ .//
    \\\..           .-=3D  t.r.u.s.t  n.0  o.n.e  =3D-.            ..///

--y0ulUmNC+osPPQO6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5nOe+9uSLtLrzBfMRApWWAJ9rZ2IY1BtEYaptu9512r39byA5ngCffnkl
mWY6Og7ivZml9Utgf2lnIQk=
=chmP
-----END PGP SIGNATURE-----

--y0ulUmNC+osPPQO6--

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Sat Aug 19 15:27:30 2000
Received: by humbolt.nl.linux.org id <S92423AbQHSNYW>;
	Sat, 19 Aug 2000 15:24:22 +0200
Received: from ob1.TheForce.com.au ([203.18.20.200]:2569 "EHLO
        ob1.theforce.com.au") by humbolt.nl.linux.org with ESMTP
	id <S92351AbQHSNXW>; Sat, 19 Aug 2000 15:23:22 +0200
Received: from localhost (gbj@localhost)
	by ob1.theforce.com.au (8.9.3/8.9.3) with ESMTP id XAA14525
	for <kernel-audit@nl.linux.org>; Sat, 19 Aug 2000 23:24:17 +1000
Date:   Sat, 19 Aug 2000 23:24:17 +1000 (EST)
From:   Grahame Jordan <gbj@ob1.theforce.com.au>
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
In-Reply-To: <20000818093734.A1004@localhost>
Message-ID: <Pine.LNX.4.21.0008192319540.12481-100000@ob1.theforce.com.au>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

All,

Why have swap at all.  Just use lots of RAM :).  

Mmmm? Can RAM be deseminated too?

Grahame Jordan

-- 
-----------------------
- I see, I forget;    -
- I read I know;      - (Understanding Year 1&2 Maths)
- I do, I understand. -       (Alan Horsfield)
-----------------------


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Sat Aug 19 20:59:54 2000
Received: by humbolt.nl.linux.org id <S92368AbQHSS5K>;
	Sat, 19 Aug 2000 20:57:10 +0200
Received: from smtp-1.worldonline.cz ([195.146.100.76]:36822 "EHLO
        smtp.worldonline.cz") by humbolt.nl.linux.org with ESMTP
	id <S92407AbQHSS4I>; Sat, 19 Aug 2000 20:56:08 +0200
Received: from localhost.localdomain (ppp88.ul.worldonline.cz [212.11.96.90])
	by smtp.worldonline.cz (8.9.3 (WOL 1.2)/8.9.3) with ESMTP id UAA12076
	for <kernel-audit@nl.linux.org>; Sat, 19 Aug 2000 20:55:00 +0200 (MET DST)
Received: by localhost.localdomain (Postfix, from userid 500)
	id 41F1621E3; Sat, 19 Aug 2000 17:05:38 +0200 (CEST)
Date:   Sat, 19 Aug 2000 17:05:38 +0200
From:   Martin Macok <martin.macok@underground.cz>
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
Message-ID: <20000819170538.H946@localhost>
Mail-Followup-To: kernel-audit@nl.linux.org
References: <20000818093734.A1004@localhost> <Pine.LNX.4.21.0008192319540.12481-100000@ob1.theforce.com.au>
Mime-Version: 1.0
Content-Type: multipart/signed; micalg=pgp-md5;
	protocol="application/pgp-signature"; boundary="rz+pwK2yUstbofK6"
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <Pine.LNX.4.21.0008192319540.12481-100000@ob1.theforce.com.au>; from gbj@ob1.theforce.com.au on Sat, Aug 19, 2000 at 11:24:17PM +1000
X-Echelon: NSA GCHQ KGB CIA nuclear conspiration war weapon spy agent
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


--rz+pwK2yUstbofK6
Content-Type: text/plain; charset=iso-8859-2
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Sat, Aug 19, 2000 at 11:24:17PM +1000, Grahame Jordan wrote:
> Why have swap at all.  Just use lots of RAM :). =20

Can you have 512MB RAM or more in your notebook? ;-) (thinking about Star
Office 5.2, Mozilla, GNOME/KDE, VMWare and thinks like that).

Swap is not only good for short-of-memory reasons. It's good for swapping
out memory from stuff that is used rarely to make more memory for
processes that needes it right now. It's also good for things like
suspending OS ...

/* And there is also no way to make no swap in OpenBSD cause of race
conditions ... (but AFAIK Linux can live without swap). */

> Mmmm? Can RAM be deseminated too?

No, conventional RAM not (or it could be extremely expensive and
difficult, nearly impossible). But there are some atempts to make RAM with
latent memory for future, maybe after 2-3 years it would be usual.

I propose killing this thread. As somebody noted before - inventing new
features is definitely NOT KERNEL AUDITING.=20

Have a nice day

--=20
< Martin Ma=E8ok        martin.macok@underground.cz           <iso-8859-2>=
=20
  \\. http://kocour.ms.mff.cuni.cz/~macok/  http://underground.cz/ .//
    \\\..           .-=3D  t.r.u.s.t  n.0  o.n.e  =3D-.            ..///

--rz+pwK2yUstbofK6
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.1 (GNU/Linux)
Comment: For info see http://www.gnupg.org

iD8DBQE5nqJC9uSLtLrzBfMRAifSAKC1qZBxYx4Gl/Qm1lUNuJOk6D3oawCcD3qH
nqcAUCMtZks6XpquVB76ilM=
=JWwZ
-----END PGP SIGNATURE-----

--rz+pwK2yUstbofK6--

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Sun Aug 20 20:40:37 2000
Received: by humbolt.nl.linux.org id <S92183AbQHTSjW>;
	Sun, 20 Aug 2000 20:39:22 +0200
Received: from mercury.rus.uni-stuttgart.de ([129.69.1.226]:61969 "EHLO
        mercury.rus.uni-stuttgart.de") by humbolt.nl.linux.org with ESMTP
	id <S92166AbQHTSiz>; Sun, 20 Aug 2000 20:38:55 +0200
Received: from rusfw by mercury.rus.uni-stuttgart.de with local (Exim 3.12 #4)
	id 13QZy6-0004uY-00
	for kernel-audit@nl.linux.org; Sun, 20 Aug 2000 20:37:14 +0200
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
References: <Pine.OSF.4.20.0008171200470.1162-100000@sirppi.helsinki.fi>
From:   Florian Weimer <Florian.Weimer@RUS.Uni-Stuttgart.DE>
Date:   20 Aug 2000 20:37:14 +0200
In-Reply-To: Anders M Montonen's message of "Thu, 17 Aug 2000 12:09:57 +0300 (EET DST)"
Message-ID: <tg4s4f6ap1.fsf@mercury.rus.uni-stuttgart.de>
Lines:  14
User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/20.7
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Anders M Montonen <ammonton@cc.helsinki.fi> writes:

> That, and the fact that the R/W head doesn't pass *exactly* over the old
> track when writing, leaves enough of a trace to read the old data. There
> are companies providing this type of service, eg. www.ibas.no. It is
> extremely expensive, but if your harddrive containing vital information
> burned up in a fire, chances are they can still read it.

Data recovery from hard drives has become considerably cheaper during
the last few years.  In fact, recovery from disk crashes is so cheap
nowadays that making backups is hardly worth the trouble. ;-)

Of course, recovery of overwritten data still pays extra, but I
wouldn't count on your data having less value than the recovery costs.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug 21 06:46:49 2000
Received: by humbolt.nl.linux.org id <S92185AbQHUEpp>;
	Mon, 21 Aug 2000 06:45:45 +0200
Received: from nsm.htp.org ([202.241.243.104]:51980 "HELO nsm.htp.org")
	by humbolt.nl.linux.org with SMTP id <S92170AbQHUEpI>;
	Mon, 21 Aug 2000 06:45:08 +0200
Received: (qmail 4755 invoked from network); 21 Aug 2000 04:42:21 -0000
Received: from localhost (127.0.0.1)
  by localhost with SMTP; 21 Aug 2000 04:42:21 -0000
To:     kernel-audit@nl.linux.org
Subject: Re: encrypting swap
From:   sen_ml@eccosys.com
In-Reply-To: <20000819170538.H946@localhost>
References: <20000818093734.A1004@localhost>
	<Pine.LNX.4.21.0008192319540.12481-100000@ob1.theforce.com.au>
	<20000819170538.H946@localhost>
X-Mailer: Mew version 1.94.2 on Emacs 20.7 / Mule 4.0 (HANANOEN)
X-No-Archive: Yes
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20000821134413C.1001@eccosys.com>
Date:   Mon, 21 Aug 2000 13:44:13 +0900
X-Dispatcher: imput version 20000228(IM140)
Lines:  14
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

From: Martin Macok <martin.macok@underground.cz>
Subject: Re: encrypting swap
Date: Sat, 19 Aug 2000 17:05:38 +0200
Message-ID: <20000819170538.H946@localhost>

> On Sat, Aug 19, 2000 at 11:24:17PM +1000, Grahame Jordan wrote:
> > Why have swap at all.  Just use lots of RAM :).  
> 
> Can you have 512MB RAM or more in your notebook? ;-) (thinking about Star
> Office 5.2, Mozilla, GNOME/KDE, VMWare and thinks like that).

some thinkpad models go up to at least 512 -- there seems to be a
general trend toward reducing max ram in notebooks these days
though...

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 09:08:06 2000
Received: by humbolt.nl.linux.org id <S92184AbQHXHGn>;
	Thu, 24 Aug 2000 09:06:43 +0200
Received: from kembara.extern.ui.ac.id ([202.155.17.130]:2823 "EHLO
        indovax.ui.ac.id") by humbolt.nl.linux.org with ESMTP
	id <S92185AbQHXHGH>; Thu, 24 Aug 2000 09:06:07 +0200
Received: from uicsgtw.cs.ui.ac.id (uicsgtw.cs.ui.ac.id [152.118.24.8])
	by indovax.ui.ac.id (8.9.2/8.9.2) with ESMTP id OAA05562
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 14:05:15 +0700 (JAVT)
Received: from puspa.cs.ui.ac.id (puspa.cs.ui.ac.id [152.118.24.5])
	by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with ESMTP id OAA00730
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 14:05:09 +0700
Received: from localhost (joe197@localhost)
	by puspa.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with SMTP id OAA01875
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 14:05:11 +0700
Date:   Thu, 24 Aug 2000 07:05:10 +0000 (GMT)
From:   "johan '97" <joe197@puspa.cs.ui.ac.id>
To:     kernel-audit@nl.linux.org
Subject: false asumption or security flaw?
Message-ID: <Pine.LNX.3.96.1000824070018.857B-100000@puspa.cs.ui.ac.id>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

hi,

could anyone tell me why does this piece of code does not dump?
<start>

#include <stdio.h>
#include <stdlib.h>
main()
{
	int *x=(int*)malloc(sizeof(int));
	*x=8;

	int &a=(*x);

	printf("\na dan x : %d %d", a, *x);

	a = 9;

	printf("\na dan x : %d %d", a, *x);

	free(x);

	a=5;

	return 0;
}

<end>

could it be a security flaw in the kernel?

thanx

johan
surrendered, i have


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 10:18:39 2000
Received: by humbolt.nl.linux.org id <S92268AbQHXIRN>;
	Thu, 24 Aug 2000 10:17:13 +0200
Received: from localhost.gumbynet.org ([203.42.225.1]:20494 "EHLO
        localhost.gumbynet.org") by humbolt.nl.linux.org with ESMTP
	id <S92267AbQHXIQt>; Thu, 24 Aug 2000 10:16:49 +0200
Received: from box3n.gumbynet.org (box3n.gumbynet.org [203.43.214.254])
	by localhost.gumbynet.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id SAA09941;
	Thu, 24 Aug 2000 18:16:33 +1000
Received: from localhost (fyre@localhost)
	by box3n.gumbynet.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id SAA16318;
	Thu, 24 Aug 2000 18:16:46 +1000
Date:   Thu, 24 Aug 2000 18:16:45 +1000 (EST)
From:   Tim Robbins <fyre@box3n.gumbynet.org>
To:     "johan '97" <joe197@puspa.cs.ui.ac.id>
cc:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw?
In-Reply-To: <Pine.LNX.3.96.1000824070018.857B-100000@puspa.cs.ui.ac.id>
Message-ID: <Pine.LNX.4.21.0008241814460.16238-100000@box3n.gumbynet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

You're creating a reference of type int (int &) with the value of 8 in a
roundabout kind of way. Yuck. That shouldn't dump core because it does
nothing wrong, but whatever you're trying to do I'll bet that isn't the
right way to do it :)


--
Tim Robbins
fyre@box3n.gumbynet.org

On Thu, 24 Aug 2000, johan '97 wrote:

> hi,
> 
> could anyone tell me why does this piece of code does not dump?
> <start>
> 
> #include <stdio.h>
> #include <stdlib.h>
> main()
> {
> 	int *x=(int*)malloc(sizeof(int));
> 	*x=8;
> 
> 	int &a=(*x);
> 
> 	printf("\na dan x : %d %d", a, *x);
> 
> 	a = 9;
> 
> 	printf("\na dan x : %d %d", a, *x);
> 
> 	free(x);
> 
> 	a=5;
> 
> 	return 0;
> }
> 
> <end>
> 
> could it be a security flaw in the kernel?
> 
> thanx
> 
> johan
> surrendered, i have
> 
> 
> Kernel-audit:  discussion list for security and the linux kernel
> Archive:       http://mail.nl.linux.org/kernel-audit/
> 


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 11:38:38 2000
Received: by humbolt.nl.linux.org id <S92270AbQHXJhd>;
	Thu, 24 Aug 2000 11:37:33 +0200
Received: from kembara.extern.ui.ac.id ([202.155.17.130]:14120 "EHLO
        indovax.ui.ac.id") by humbolt.nl.linux.org with ESMTP
	id <S92267AbQHXJhA>; Thu, 24 Aug 2000 11:37:00 +0200
Received: from uicsgtw.cs.ui.ac.id (uicsgtw.cs.ui.ac.id [152.118.24.8])
	by indovax.ui.ac.id (8.9.2/8.9.2) with ESMTP id QAA13649;
	Thu, 24 Aug 2000 16:34:55 +0700 (JAVT)
Received: from puspa.cs.ui.ac.id (puspa.cs.ui.ac.id [152.118.24.5])
	by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA02986;
	Thu, 24 Aug 2000 16:08:34 +0700
Received: from localhost (joe197@localhost)
	by puspa.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA09417;
	Thu, 24 Aug 2000 16:08:36 +0700
Date:   Thu, 24 Aug 2000 09:08:36 +0000 (GMT)
From:   "johan '97" <joe197@puspa.cs.ui.ac.id>
To:     Tim Robbins <fyre@box3n.gumbynet.org>
cc:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw?
In-Reply-To: <Pine.LNX.4.21.0008241814460.16238-100000@box3n.gumbynet.org>
Message-ID: <Pine.LNX.3.96.1000824085021.8124B-100000@puspa.cs.ui.ac.id>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Thu, 24 Aug 2000, Tim Robbins wrote:

> You're creating a reference of type int (int &) with the value of 8 in a
> roundabout kind of way. Yuck. That shouldn't dump core because it does
> nothing wrong, but whatever you're trying to do I'll bet that isn't the
> right way to do it :)

the fact that i have freed the memory pointed by 'x', but still "legally" 
can be accessed by the reference variable 'a' (shown by the no dumping
off the program)  should imply that this piece of memory can be allocated
not only to one user/process but also many user/process which can be
devestating in effect!

i don't know much about how the kernel manages the memory areas to the
users/processes, so may be a knowledge about how the kernel does things
in the memory would be helpful here. hints from the experts, please :)

fyi: if i added this code here
> On Thu, 24 Aug 2000, johan '97 wrote:
> > #include <stdio.h>
> > #include <stdlib.h>
> > main()
> > {
> > 	int *x=(int*)malloc(sizeof(int));
> > 	*x=8;
> > 
> > 	int &a=(*x);
> > 
> > 	printf("\na dan x : %d %d", a, *x);
> > 
> > 	a = 9;
> > 
> > 	printf("\na dan x : %d %d", a, *x);
> > 
> > 	free(x);
> > 
> > 	a=5;
/*additional code here*/
	free(x);
> > 
> > 	return 0;
> > }
the program would dump!
i guess this means that the memmory manager consider the memory pointed by
'x' does no longer exist, hence the act of changing it's content is
"illegal" , BUT this was proved wrong by the piece of code:
'a=5;' 

i think this is serious!

johan
surrendered, i have


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 11:46:19 2000
Received: by humbolt.nl.linux.org id <S92277AbQHXJpE>;
	Thu, 24 Aug 2000 11:45:04 +0200
Received: from kembara.extern.ui.ac.id ([202.155.17.130]:40246 "EHLO
        indovax.ui.ac.id") by humbolt.nl.linux.org with ESMTP
	id <S92271AbQHXJoh>; Thu, 24 Aug 2000 11:44:37 +0200
Received: from uicsgtw.cs.ui.ac.id (uicsgtw.cs.ui.ac.id [152.118.24.8])
	by indovax.ui.ac.id (8.9.2/8.9.2) with ESMTP id QAA14044
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 16:43:52 +0700 (JAVT)
Received: from puspa.cs.ui.ac.id (puspa.cs.ui.ac.id [152.118.24.5])
	by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with ESMTP id QAA03630
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 16:43:46 +0700
Received: from localhost (joe197@localhost)
	by puspa.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with SMTP id QAA10888
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 16:43:48 +0700
Date:   Thu, 24 Aug 2000 09:43:48 +0000 (GMT)
From:   "johan '97" <joe197@puspa.cs.ui.ac.id>
To:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw? (fwd)
Message-ID: <Pine.LNX.3.96.1000824094320.10826B-100000@puspa.cs.ui.ac.id>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Thu, 24 Aug 2000, Tim Robbins wrote:

> You're creating a reference of type int (int &) with the value of 8 in a
> roundabout kind of way. Yuck. That shouldn't dump core because it does
> nothing wrong, but whatever you're trying to do I'll bet that isn't the
> right way to do it :)

the fact that i have freed the memory pointed by 'x', but still "legally" 
can be accessed by the reference variable 'a' (shown by the no dumping
off the program)  should imply that this piece of memory can be allocated
not only to one user/process but also many user/process which can be
devestating in effect!

i don't know much about how the kernel manages the memory areas to the
users/processes, so may be a knowledge about how the kernel does things
in the memory would be helpful here. hints from the experts, please :)

fyi: if i added this code here
> On Thu, 24 Aug 2000, johan '97 wrote:
> > #include <stdio.h>
> > #include <stdlib.h>
> > main()
> > {
> > 	int *x=(int*)malloc(sizeof(int));
> > 	*x=8;
> > 
> > 	int &a=(*x);
> > 
> > 	printf("\na dan x : %d %d", a, *x);
> > 
> > 	a = 9;
> > 
> > 	printf("\na dan x : %d %d", a, *x);
> > 
> > 	free(x);
> > 
> > 	a=5;
/*additional code here*/
	free(x);
> > 
> > 	return 0;
> > }
the program would dump!
i guess this means that the memmory manager consider the memory pointed by
'x' does no longer exist, hence the act of changing it's content is
"illegal" , BUT this was proved wrong by the piece of code:
'a=5;' 

i think this is serious!

johan
surrendered, i have



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 12:00:40 2000
Received: by humbolt.nl.linux.org id <S92272AbQHXJ7M>;
	Thu, 24 Aug 2000 11:59:12 +0200
Received: from zada.math.leidenuniv.nl ([132.229.231.3]:44817 "EHLO
        zada.math.leidenuniv.nl") by humbolt.nl.linux.org with ESMTP
	id <S92267AbQHXJ6j>; Thu, 24 Aug 2000 11:58:39 +0200
Received: from mara.math.leidenuniv.nl (mara.math.leidenuniv.nl [132.229.232.80])
	by zada.math.leidenuniv.nl (8.9.3/8.9.3) with ESMTP id LAA31326;
	Thu, 24 Aug 2000 11:57:52 +0200
Date:   Thu, 24 Aug 2000 11:57:52 +0200 (CEST)
From:   Lennert Buytenhek <buytenh@gnu.org>
X-Sender: buytenh@mara.math.leidenuniv.nl
To:     "johan '97" <joe197@puspa.cs.ui.ac.id>
cc:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw? (fwd)
In-Reply-To: <Pine.LNX.3.96.1000824094320.10826B-100000@puspa.cs.ui.ac.id>
Message-ID: <Pine.LNX.4.21.0008241154300.13676-100000@mara.math.leidenuniv.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


Hi,

After you free that chunk of memory, the page it is in probably still
belongs to that process, so it cannot be 'shared' with other processes.
Nothing serious here. However, the glibc memory allocator will probably
put some of its own stuff in that chunk of memory and might hand it out to
another malloc() call later on in your program. In essence, you're causing
random memory corruption. Things like Electric Fence are meant to help
catch these programming errors (because, yes, they are considered
programming errors).

I think you need to read a good book on operating system internals.


greetings,
Lennert


On Thu, 24 Aug 2000, johan '97 wrote:

> > You're creating a reference of type int (int &) with the value of 8 in a
> > roundabout kind of way. Yuck. That shouldn't dump core because it does
> > nothing wrong, but whatever you're trying to do I'll bet that isn't the
> > right way to do it :)
> 
> the fact that i have freed the memory pointed by 'x', but still "legally" 
> can be accessed by the reference variable 'a' (shown by the no dumping
> off the program)  should imply that this piece of memory can be allocated
> not only to one user/process but also many user/process which can be
> devestating in effect!
> 
> i don't know much about how the kernel manages the memory areas to the
> users/processes, so may be a knowledge about how the kernel does things
> in the memory would be helpful here. hints from the experts, please :)
> 
> fyi: if i added this code here
> > On Thu, 24 Aug 2000, johan '97 wrote:
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > main()
> > > {
> > > 	int *x=(int*)malloc(sizeof(int));
> > > 	*x=8;
> > > 
> > > 	int &a=(*x);
> > > 
> > > 	printf("\na dan x : %d %d", a, *x);
> > > 
> > > 	a = 9;
> > > 
> > > 	printf("\na dan x : %d %d", a, *x);
> > > 
> > > 	free(x);
> > > 
> > > 	a=5;
> /*additional code here*/
> 	free(x);
> > > 
> > > 	return 0;
> > > }
> the program would dump!
> i guess this means that the memmory manager consider the memory pointed by
> 'x' does no longer exist, hence the act of changing it's content is
> "illegal" , BUT this was proved wrong by the piece of code:
> 'a=5;' 
> 
> i think this is serious!
> 
> johan
> surrendered, i have
> 
> 
> 
> Kernel-audit:  discussion list for security and the linux kernel
> Archive:       http://mail.nl.linux.org/kernel-audit/
> 


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 12:11:38 2000
Received: by humbolt.nl.linux.org id <S92271AbQHXKKM>;
	Thu, 24 Aug 2000 12:10:12 +0200
Received: from office.mandrakesoft.com ([195.68.114.34]:62705 "EHLO
        test1.mandrakesoft.com") by humbolt.nl.linux.org with ESMTP
	id <S92273AbQHXKJs>; Thu, 24 Aug 2000 12:09:48 +0200
Received: by test1.mandrakesoft.com (Postfix, from userid 500)
	id 385573712; Thu, 24 Aug 2000 11:09:14 +0200 (CEST)
To:     "johan '97" <joe197@puspa.cs.ui.ac.id>
Cc:     Tim Robbins <fyre@box3n.gumbynet.org>, kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw?
References: <Pine.LNX.3.96.1000824085021.8124B-100000@puspa.cs.ui.ac.id>
From:   Yoann Vandoorselaere <yoann@mandrakesoft.com>
Date:   24 Aug 2000 11:09:14 +0200
In-Reply-To: "johan '97"'s message of "Thu, 24 Aug 2000 09:08:36 +0000 (GMT)"
Message-ID: <m37l976n5x.fsf@test1.mandrakesoft.com>
Lines:  57
User-Agent: Gnus/5.0807 (Gnus v5.8.7) Emacs/20.6
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

"johan '97" <joe197@puspa.cs.ui.ac.id> writes:

> On Thu, 24 Aug 2000, Tim Robbins wrote:
> 
> > You're creating a reference of type int (int &) with the value of 8 in a
> > roundabout kind of way. Yuck. That shouldn't dump core because it does
> > nothing wrong, but whatever you're trying to do I'll bet that isn't the
> > right way to do it :)
> 
> the fact that i have freed the memory pointed by 'x', but still "legally" 
> can be accessed by the reference variable 'a' (shown by the no dumping
> off the program)  should imply that this piece of memory can be allocated
> not only to one user/process but also many user/process which can be
> devestating in effect!

Ok, I don't know for reference,
but I assume that is the same logic as pointer one.

So, let's write this exemple in C :


int main () {
    int *x = (int *) malloc(sizeof(int));
    int *a;

    *x = 9;
    a = x;

    printf("%d, %d\n", *a, *x);

    *a = 3;

    printf("%d, %d\n", *a, *x);

    free(x);

    *a = 10;

    printf("%d, %d\n", *a, *x);
}

9, 9
3, 3
10, 10

After having freed "x", "a" is a dangling pointer,
which mean that it point to an address in memory, which,
*for this case* was referenced but isn't anymore.

The result in this case is undefined,
I assume that you do not core because the address do not
point outside your process address space.

-- 
                -- Yoann http://www.mandrakesoft.com/~yoann/
An engineer from NVidia, while asking him to release cards specs said :
- "Actually, we do write our drivers without documentation."

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 12:32:51 2000
Received: by humbolt.nl.linux.org id <S92267AbQHXKbo>;
	Thu, 24 Aug 2000 12:31:44 +0200
Received: from kembara.extern.ui.ac.id ([202.155.17.130]:46602 "EHLO
        indovax.ui.ac.id") by humbolt.nl.linux.org with ESMTP
	id <S92214AbQHXKbN>; Thu, 24 Aug 2000 12:31:13 +0200
Received: from uicsgtw.cs.ui.ac.id (uicsgtw.cs.ui.ac.id [152.118.24.8])
	by indovax.ui.ac.id (8.9.2/8.9.2) with ESMTP id RAA16105;
	Thu, 24 Aug 2000 17:30:08 +0700 (JAVT)
Received: from puspa.cs.ui.ac.id (puspa.cs.ui.ac.id [152.118.24.5])
	by uicsgtw.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with ESMTP id RAA04271;
	Thu, 24 Aug 2000 17:30:02 +0700
Received: from localhost (joe197@localhost)
	by puspa.cs.ui.ac.id (8.9.3/8.9.3/Debian/GNU) with SMTP id RAA13923;
	Thu, 24 Aug 2000 17:30:05 +0700
Date:   Thu, 24 Aug 2000 10:30:04 +0000 (GMT)
From:   "johan '97" <joe197@puspa.cs.ui.ac.id>
To:     Lennert Buytenhek <buytenh@gnu.org>
cc:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw? (fwd)
In-Reply-To: <Pine.LNX.4.21.0008241154300.13676-100000@mara.math.leidenuniv.nl>
Message-ID: <Pine.LNX.3.96.1000824101058.10826C-100000@puspa.cs.ui.ac.id>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Thu, 24 Aug 2000, Lennert Buytenhek wrote:
> 
> Hi,
> 
> After you free that chunk of memory, the page it is in probably still
> belongs to that process, so it cannot be 'shared' with other processes.
> Nothing serious here. However, the glibc memory allocator will probably
so, in other words
the function malloc gets it's memory from an already allocated memory (by the 
kernel to the process) and hands it to the program to be used.
once this chunk of memory is freed by the program, it is (probably?) still
a part of the memory that is allocated to the process by the kernel.
The kernel 'knows' that this chunk is still in use by the process,
but the program 'thinks' differently. Hence, the probability of a chaos
to happen is limited only in the process and not the kernel.

in a nut shell, it's more of the compilers inability to detect these sort
of situation than a flaw in the kernel security.

is this correct?

> I think you need to read a good book on operating system internals.
> greetings,
> Lennert
> On Thu, 24 Aug 2000, johan '97 wrote:
> 
> > > You're creating a reference of type int (int &) with the value of 8 in a
> > > roundabout kind of way. Yuck. That shouldn't dump core because it does
> > > nothing wrong, but whatever you're trying to do I'll bet that isn't the
> > > right way to do it :)
> > 
> > the fact that i have freed the memory pointed by 'x', but still "legally" 
> > can be accessed by the reference variable 'a' (shown by the no dumping
> > off the program)  should imply that this piece of memory can be allocated
> > not only to one user/process but also many user/process which can be
> > devestating in effect!
> > 
> > i don't know much about how the kernel manages the memory areas to the
> > users/processes, so may be a knowledge about how the kernel does things
> > in the memory would be helpful here. hints from the experts, please :)
> > 
> > fyi: if i added this code here
> > > On Thu, 24 Aug 2000, johan '97 wrote:
> > > > #include <stdio.h>
> > > > #include <stdlib.h>
> > > > main()
> > > > {
> > > > 	int *x=(int*)malloc(sizeof(int));
> > > > 	*x=8;
> > > > 
> > > > 	int &a=(*x);
> > > > 
> > > > 	printf("\na dan x : %d %d", a, *x);
> > > > 
> > > > 	a = 9;
> > > > 
> > > > 	printf("\na dan x : %d %d", a, *x);
> > > > 
> > > > 	free(x);
> > > > 
> > > > 	a=5;
> > /*additional code here*/
> > 	free(x);
> > > > 
> > > > 	return 0;
> > > > }
> > the program would dump!
> > i guess this means that the memmory manager consider the memory pointed by
> > 'x' does no longer exist, hence the act of changing it's content is
> > "illegal" , BUT this was proved wrong by the piece of code:
> > 'a=5;' 
> > 
> > i think this is serious!
> 

johan
surrendered, i have


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 12:42:20 2000
Received: by humbolt.nl.linux.org id <S92214AbQHXKlE>;
	Thu, 24 Aug 2000 12:41:04 +0200
Received: from zada.math.leidenuniv.nl ([132.229.231.3]:2066 "EHLO
        zada.math.leidenuniv.nl") by humbolt.nl.linux.org with ESMTP
	id <S92195AbQHXKki>; Thu, 24 Aug 2000 12:40:38 +0200
Received: from mara.math.leidenuniv.nl (mara.math.leidenuniv.nl [132.229.232.80])
	by zada.math.leidenuniv.nl (8.9.3/8.9.3) with ESMTP id MAA00489;
	Thu, 24 Aug 2000 12:39:57 +0200
Date:   Thu, 24 Aug 2000 12:39:57 +0200 (CEST)
From:   Lennert Buytenhek <buytenh@gnu.org>
X-Sender: buytenh@mara.math.leidenuniv.nl
To:     "johan '97" <joe197@puspa.cs.ui.ac.id>
cc:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw? (fwd)
In-Reply-To: <Pine.LNX.3.96.1000824101058.10826C-100000@puspa.cs.ui.ac.id>
Message-ID: <Pine.LNX.4.21.0008241231560.13921-100000@mara.math.leidenuniv.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list



On Thu, 24 Aug 2000, johan '97 wrote:

> > Hi,
> > 
> > After you free that chunk of memory, the page it is in probably still
> > belongs to that process, so it cannot be 'shared' with other processes.
> > Nothing serious here. However, the glibc memory allocator will probably
>
> so, in other words
> the function malloc gets it's memory from an already allocated memory
> (by the kernel to the process) and hands it to the program to be used.

Yes. Unless the memory allocated to this process is full, in which case
this processes requests a new chunk of memory from the kernel. These
chunks of memory are zeroed before they are handed to processes though.


> once this chunk of memory is freed by the program, it is (probably?)
> still a part of the memory that is allocated to the process by the
> kernel.

Yup.


> The kernel 'knows' that this chunk is still in use by the process,

Yup.


> but the program 'thinks' differently.

Well, no. The program knows it has this memory allocated, but if you free
it it is marked as being free :)


> Hence, the probability of a chaos to happen is limited only in the
> process and not the kernel.

Not if you follow some basic programming rules. Like.. dont use a pointer
after you free it.


> in a nut shell, it's more of the compilers inability to detect these
> sort of situation than a flaw in the kernel security.

It's definitely not a problem with kernel security. And whether this kind
of checking belongs in the compiler is subject of religious wars.

If you really want your language to do these kinds of things for you you
probably should be using perl or something.



greetings,
Lennert


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 13:44:20 2000
Received: by humbolt.nl.linux.org id <S92233AbQHXLmz>;
	Thu, 24 Aug 2000 13:42:55 +0200
Received: from hawk.prod.itd.earthlink.net ([207.217.120.22]:20105 "EHLO
        hawk.prod.itd.earthlink.net") by humbolt.nl.linux.org with ESMTP
	id <S92195AbQHXLmS>; Thu, 24 Aug 2000 13:42:18 +0200
Received: from earthlink.net (ip51.laurel4.md.pub-ip.psi.net [38.30.238.51])
	by hawk.prod.itd.earthlink.net (8.9.3-EL_1_3/8.9.3) with ESMTP id EAA21732;
	Thu, 24 Aug 2000 04:41:31 -0700 (PDT)
Message-ID: <39A509C4.F83A57EA@earthlink.net>
Date:   Thu, 24 Aug 2000 07:40:52 -0400
From:   Michael DiCuccio <dicuccio@earthlink.net>
X-Mailer: Mozilla 4.73 [en] (X11; U; Linux 2.2.16 i686)
X-Accept-Language: en
MIME-Version: 1.0
To:     "johan '97" <joe197@puspa.cs.ui.ac.id>
CC:     Lennert Buytenhek <buytenh@gnu.org>, kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw? (fwd)
References: <Pine.LNX.3.96.1000824101058.10826C-100000@puspa.cs.ui.ac.id>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

I think the real issue here is what happens inside of malloc().  Someone
correct me if my assumptions are wrong, but malloc() grabs a chunk of
memory and glibc holds on to it after it is free()'d.  This memory is
still owned by this process and protected from other processes.  The
glibc info pages have some details on malloc() internals which may help
explain this.

-- 
-----
Mike DiCuccio

"Somebody obviously thinks I'm Mr. Silly!"

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 14:23:41 2000
Received: by humbolt.nl.linux.org id <S92237AbQHXMWQ>;
	Thu, 24 Aug 2000 14:22:16 +0200
Received: from user33-128.jakinternet.co.uk ([212.41.33.128]:797 "EHLO
        linux.home") by humbolt.nl.linux.org with ESMTP id <S92195AbQHXMVk>;
	Thu, 24 Aug 2000 14:21:40 +0200
Received: from localhost (mistral@localhost)
	by linux.home (8.9.3/8.9.3) with ESMTP id LAA12434
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 11:55:05 GMT
Date:   Thu, 24 Aug 2000 11:55:05 +0000 (GMT)
From:   James Stevenson <mistral@stevenson.zetnet.co.uk>
To:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw? (fwd)
In-Reply-To: <Pine.LNX.3.96.1000824094320.10826B-100000@puspa.cs.ui.ac.id>
Message-ID: <Pine.LNX.4.21.0008241152060.12432-100000@linux.home>
X-mailer: Pine 4.21
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list


Hi

the reson why the program will not dump is becuase it is done by a 4k
page system and the page has not been freed by the proggram because it
probably has something else in it and then the same page will not be
alloced to another process

somebody please correct me if i am wrong :)

cya
	James

> On Thu, 24 Aug 2000, Tim Robbins wrote:
> 
> 
> the fact that i have freed the memory pointed by 'x', but still "legally" 
> can be accessed by the reference variable 'a' (shown by the no dumping
> off the program)  should imply that this piece of memory can be allocated
> not only to one user/process but also many user/process which can be
> devestating in effect!
> 
> i don't know much about how the kernel manages the memory areas to the
> users/processes, so may be a knowledge about how the kernel does things
> in the memory would be helpful here. hints from the experts, please :)
> 

-- 
---------------------------------------------
Check Out: http://www.users.zetnet.co.uk/james/
E-Mail: mistral@stevenson.zetnet.co.uk
 11:50am  up 2 days, 22:02,  8 users,  load average: 0.45, 0.42, 0.43


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 14:44:20 2000
Received: by humbolt.nl.linux.org id <S92252AbQHXMm4>;
	Thu, 24 Aug 2000 14:42:56 +0200
Received: from gwa2.fe.bosch.de ([194.39.218.2]:21686 "EHLO gwa2.fe.bosch.de")
	by humbolt.nl.linux.org with ESMTP id <S92195AbQHXMm1>;
	Thu, 24 Aug 2000 14:42:27 +0200
Received: (from uucp@localhost)
	by gwa2.fe.bosch.de (8.9.1/8.9.1) id MAA22208
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 12:42:25 GMT
Received: from fez8020.fe.bosch.de(virus-out2.fe.internet.bosch.de 10.4.4.20) by gwa2.fe.bosch.de via smap (V2.1)
	id xma021033; Thu, 24 Aug 00 12:41:10 GMT
Received: by fez7202.server.bosch.de with Internet Mail Service (5.5.2651.58)
	id <RQQM5L3Q>; Thu, 24 Aug 2000 14:41:01 +0200
Message-ID: <4BA83203985FD411A34A00508B69D83107F10E@frmail3.fr.bosch.de>
From:   "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
To:     "'James Stevenson'" <mistral@stevenson.zetnet.co.uk>,
        kernel-audit@nl.linux.org
Subject: RE: false asumption or security flaw? (fwd)
Date:   Thu, 24 Aug 2000 14:40:56 +0200
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2651.58)
Content-Type: text/plain;
	charset="iso-8859-1"
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

> the reson why the program will not dump is becuase it is done by a 4k
> page system and the page has not been freed by the proggram because it
> probably has something else in it and then the same page will not be
> alloced to another process
> 
> somebody please correct me if i am wrong :)

That's right. Memory protection is always page-grained (4kB). 
And there's only one reliable, transparent, and low-overhead 
mechanism to control the access to memory pages: the one 
implemented in the MMU of the CPU.

If you want to cause a seg-fault, you have to do:

	int *ip; ip = 0; *ip = 0; /* :-) */

This works because the zero-page is write-protected (to
catch exactly these null-pointer reference errors).

Have fun.

Thomas.

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 16:05:55 2000
Received: by humbolt.nl.linux.org id <S92274AbQHXOEj>;
	Thu, 24 Aug 2000 16:04:39 +0200
Received: from zada.math.leidenuniv.nl ([132.229.231.3]:50706 "EHLO
        zada.math.leidenuniv.nl") by humbolt.nl.linux.org with ESMTP
	id <S92219AbQHXOEH>; Thu, 24 Aug 2000 16:04:07 +0200
Received: from mara.math.leidenuniv.nl (mara.math.leidenuniv.nl [132.229.232.80])
	by zada.math.leidenuniv.nl (8.9.3/8.9.3) with ESMTP id QAA05550;
	Thu, 24 Aug 2000 16:03:40 +0200
Date:   Thu, 24 Aug 2000 16:03:40 +0200 (CEST)
From:   Lennert Buytenhek <buytenh@gnu.org>
X-Sender: buytenh@mara.math.leidenuniv.nl
To:     "Strohm Thomas (FV/SLD) *" <Thomas.Strohm@de.bosch.com>
cc:     "'James Stevenson'" <mistral@stevenson.zetnet.co.uk>,
        kernel-audit@nl.linux.org
Subject: RE: false asumption or security flaw? (fwd)
In-Reply-To: <4BA83203985FD411A34A00508B69D83107F10E@frmail3.fr.bosch.de>
Message-ID: <Pine.LNX.4.21.0008241601570.15203-100000@mara.math.leidenuniv.nl>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list



On Thu, 24 Aug 2000, Strohm Thomas (FV/SLD) * wrote:

> > the reson why the program will not dump is becuase it is done by a 4k
> > page system and the page has not been freed by the proggram because it
> > probably has something else in it and then the same page will not be
> > alloced to another process
> > 
> > somebody please correct me if i am wrong :)
> 
> That's right. Memory protection is always page-grained (4kB).

To be really nit-picking: not every architecture has 4kb-sized pages :-)


greetings,
Lennert


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 16:32:30 2000
Received: by humbolt.nl.linux.org id <S92219AbQHXObI>;
	Thu, 24 Aug 2000 16:31:08 +0200
Received: from smtp09.phx.gblx.net ([206.165.6.139]:53458 "EHLO
        smtp09.phx.gblx.net") by humbolt.nl.linux.org with ESMTP
	id <S92195AbQHXOah> convert rfc822-to-8bit; Thu, 24 Aug 2000 16:30:37 +0200
Received: (from daemon@localhost)
	by smtp09.phx.gblx.net (8.9.3/8.9.3) id HAA30078
	for <kernel-audit@nl.linux.org>; Thu, 24 Aug 2000 07:30:35 -0700
Received: from 208-49-58-75.dsl1.BRV.gblx.net(208.49.58.75), claiming to be "aristotle"
 via SMTP by smtp09.phx.gblx.net, id smtpd4ngYia; Thu Aug 24 07:30:31 2000
From:   David Wagle <dwagle@frontiernet.net>
Date:   Thu, 24 Aug 2000 14:31:43 GMT
Message-ID: <20000824.14314349@mis.configured.host>
Subject: Please remove me from this list
To:     kernel-audit@nl.linux.org
X-Mailer: Mozilla/3.0 (compatible; StarOffice/5.2;Win32)
X-Priority: 3 (Normal)
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8BIT
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

thanks

Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Thu Aug 24 20:08:25 2000
Received: by humbolt.nl.linux.org id <S92269AbQHXSHB>;
	Thu, 24 Aug 2000 20:07:01 +0200
Received: from picard.csi.cc ([204.17.222.1]:47633 "EHLO picard.csihq.com")
	by humbolt.nl.linux.org with ESMTP id <S92195AbQHXSG2>;
	Thu, 24 Aug 2000 20:06:28 +0200
Received: from mblack (mblack.csihq.com [204.17.222.225])
	by picard.csihq.com (8.11.0/8.11.0) with SMTP id e7OI62O20600;
	Thu, 24 Aug 2000 14:06:02 -0400
Message-ID: <021601c00df5$f6800eb0$e1de11cc@csihq.com>
From:   "Mike Black" <mblack@csihq.com>
To:     "johan '97" <joe197@puspa.cs.ui.ac.id>, <kernel-audit@nl.linux.org>
References: <Pine.LNX.3.96.1000824070018.857B-100000@puspa.cs.ui.ac.id>
Subject: Re: false asumption or security flaw?
Date:   Thu, 24 Aug 2000 14:06:01 -0400
MIME-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Some machines have the first 256 bytes open to read but not write (no
segmentation fault either).
Others will segfault trying to even read the first 256 bytes.
I forget which architectures do this but I ran into the problem a few years
ago when porting code from one platform to another.

________________________________________
Michael D. Black   Principal Engineer
mblack@csihq.com  321-676-2923,x203
http://www.csihq.com  Computer Science Innovations
http://www.csihq.com/~mike  My home page
FAX 321-676-2355
----- Original Message -----
From: "johan '97" <joe197@puspa.cs.ui.ac.id>
To: <kernel-audit@nl.linux.org>
Sent: Thursday, August 24, 2000 3:05 AM
Subject: false asumption or security flaw?


hi,

could anyone tell me why does this piece of code does not dump?
<start>

#include <stdio.h>
#include <stdlib.h>
main()
{
int *x=(int*)malloc(sizeof(int));
*x=8;

int &a=(*x);

printf("\na dan x : %d %d", a, *x);

a = 9;

printf("\na dan x : %d %d", a, *x);

free(x);

a=5;

return 0;
}

<end>

could it be a security flaw in the kernel?

thanx

johan
surrendered, i have


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 25 03:54:08 2000
Received: by humbolt.nl.linux.org id <S92232AbQHYBwC>;
	Fri, 25 Aug 2000 03:52:02 +0200
Received: from localhost.gumbynet.org ([203.42.225.1]:28944 "EHLO
        localhost.gumbynet.org") by humbolt.nl.linux.org with ESMTP
	id <S92195AbQHYBva>; Fri, 25 Aug 2000 03:51:30 +0200
Received: from box3n.gumbynet.org (box3n.gumbynet.org [203.43.214.254])
	by localhost.gumbynet.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id LAA13517
	for <kernel-audit@nl.linux.org>; Fri, 25 Aug 2000 11:51:23 +1000
Received: from localhost (fyre@localhost)
	by box3n.gumbynet.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id LAA17692
	for <kernel-audit@nl.linux.org>; Fri, 25 Aug 2000 11:51:38 +1000
Date:   Fri, 25 Aug 2000 11:51:37 +1000 (EST)
From:   Tim Robbins <fyre@box3n.gumbynet.org>
To:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw?
In-Reply-To: <Pine.LNX.3.96.1000824085021.8124B-100000@puspa.cs.ui.ac.id>
Message-ID: <Pine.LNX.4.21.0008251147070.17658-100000@box3n.gumbynet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

References are not pointers. What you're doing in  the first example you
posted is completely legal albeit stupid. No kernel bugs. No compilers
bugs. No C Library bugs. Read up some more on references; I'm assuming
that was supposed to be the C++ reference symbol instead of the C address
of symbol. 

Playing with memory after it has been freed has undefined effects. You can
get away with it some times on some systems, but a malloc debugger such as
Perens' excellent Electric Fence will catch that kind of thing.

In conclusion, 'a' is not dynamically allocated, it is a reference
('int&').

Tim

--
Tim Robbins
fyre@box3n.gumbynet.org

On Thu, 24 Aug 2000, johan '97 wrote:

> On Thu, 24 Aug 2000, Tim Robbins wrote:
> 
> > You're creating a reference of type int (int &) with the value of 8 in a
> > roundabout kind of way. Yuck. That shouldn't dump core because it does
> > nothing wrong, but whatever you're trying to do I'll bet that isn't the
> > right way to do it :)
> 
> the fact that i have freed the memory pointed by 'x', but still "legally" 
> can be accessed by the reference variable 'a' (shown by the no dumping
> off the program)  should imply that this piece of memory can be allocated
> not only to one user/process but also many user/process which can be
> devestating in effect!
> 
> i don't know much about how the kernel manages the memory areas to the
> users/processes, so may be a knowledge about how the kernel does things
> in the memory would be helpful here. hints from the experts, please :)
> 
> fyi: if i added this code here
> > On Thu, 24 Aug 2000, johan '97 wrote:
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > main()
> > > {
> > > 	int *x=(int*)malloc(sizeof(int));
> > > 	*x=8;
> > > 
> > > 	int &a=(*x);
> > > 
> > > 	printf("\na dan x : %d %d", a, *x);
> > > 
> > > 	a = 9;
> > > 
> > > 	printf("\na dan x : %d %d", a, *x);
> > > 
> > > 	free(x);
> > > 
> > > 	a=5;
> /*additional code here*/
> 	free(x);
> > > 
> > > 	return 0;
> > > }
> the program would dump!
> i guess this means that the memmory manager consider the memory pointed by
> 'x' does no longer exist, hence the act of changing it's content is
> "illegal" , BUT this was proved wrong by the piece of code:
> 'a=5;' 
> 
> i think this is serious!
> 
> johan
> surrendered, i have
> 


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 25 04:15:32 2000
Received: by humbolt.nl.linux.org id <S92201AbQHYCOJ>;
	Fri, 25 Aug 2000 04:14:09 +0200
Received: from localhost.gumbynet.org ([203.42.225.1]:32784 "EHLO
        localhost.gumbynet.org") by humbolt.nl.linux.org with ESMTP
	id <S92195AbQHYCNe>; Fri, 25 Aug 2000 04:13:34 +0200
Received: from box3n.gumbynet.org (box3n.gumbynet.org [203.43.214.254])
	by localhost.gumbynet.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA13593
	for <kernel-audit@nl.linux.org>; Fri, 25 Aug 2000 12:13:30 +1000
Received: from localhost (fyre@localhost)
	by box3n.gumbynet.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA17752
	for <kernel-audit@nl.linux.org>; Fri, 25 Aug 2000 12:13:45 +1000
Date:   Fri, 25 Aug 2000 12:13:44 +1000 (EST)
From:   Tim Robbins <fyre@box3n.gumbynet.org>
To:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw?
In-Reply-To: <Pine.LNX.4.21.0008251147070.17658-100000@box3n.gumbynet.org>
Message-ID: <Pine.LNX.4.21.0008251208520.17658-100000@box3n.gumbynet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Sorry, I may have misunderstood what you were trying to do. In any case,
playing with pointers after they've been freed is a big no-no. I usually
give them the value NULL to 1) make it a lot more likely that access to
the pointer causes some kind of runtime error (segfault, perhaps) and
2) to mark the pointer as unused.

int *x;
if ((x = malloc (sizeof (int))) == NULL)
    abort ();
*x = 42;
free (x);
x = NULL; /* !!! */
*x = 24; /* kaboom */

Tim

--
Tim Robbins
fyre@box3n.gumbynet.org



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 25 04:43:55 2000
Received: by humbolt.nl.linux.org id <S92222AbQHYCmi>;
	Fri, 25 Aug 2000 04:42:38 +0200
Received: from localhost.gumbynet.org ([203.42.225.1]:37136 "EHLO
        localhost.gumbynet.org") by humbolt.nl.linux.org with ESMTP
	id <S92195AbQHYCmN>; Fri, 25 Aug 2000 04:42:13 +0200
Received: from box3n.gumbynet.org (box3n.gumbynet.org [203.43.214.254])
	by localhost.gumbynet.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id MAA13686
	for <kernel-audit@nl.linux.org>; Fri, 25 Aug 2000 12:42:08 +1000
Received: from localhost (fyre@localhost)
	by box3n.gumbynet.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id MAA17808
	for <kernel-audit@nl.linux.org>; Fri, 25 Aug 2000 12:42:23 +1000
Date:   Fri, 25 Aug 2000 12:42:23 +1000 (EST)
From:   Tim Robbins <fyre@box3n.gumbynet.org>
To:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw?
In-Reply-To: <m37l976n5x.fsf@test1.mandrakesoft.com>
Message-ID: <Pine.LNX.4.21.0008251237430.17796-100000@box3n.gumbynet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On 24 Aug 2000, Yoann Vandoorselaere wrote:

> Ok, I don't know for reference,
> but I assume that is the same logic as pointer one.

I just did a quick google search, found
http://cplus.about.com/compute/cplus/library/weekly/aa062500a.htm. It
nicely explains the differences between references and pointers.

"What is the difference between a pointer and  a reference ?

Even though both pointers and references look similar (as they both hold
the address of an object), they are intrinsically different. Creating a
pointer to an object creates a new object whereas creating a reference
simply creates an alternative name for an existing object."

Hope this helps,

Tim

--
Tim Robbins
fyre@box3n.gumbynet.org

..  Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS..
                            - Zippy the pinhead

Tim


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Fri Aug 25 05:02:12 2000
Received: by humbolt.nl.linux.org id <S92195AbQHYDAt>;
	Fri, 25 Aug 2000 05:00:49 +0200
Received: from localhost.gumbynet.org ([203.42.225.1]:41232 "EHLO
        localhost.gumbynet.org") by humbolt.nl.linux.org with ESMTP
	id <S92279AbQHYDAd>; Fri, 25 Aug 2000 05:00:33 +0200
Received: from box3n.gumbynet.org (box3n.gumbynet.org [203.43.214.254])
	by localhost.gumbynet.org (8.9.3/8.9.3/Debian/GNU) with ESMTP id NAA13759
	for <kernel-audit@nl.linux.org>; Fri, 25 Aug 2000 13:00:29 +1000
Received: from localhost (fyre@localhost)
	by box3n.gumbynet.org (8.9.3/8.9.3/Debian 8.9.3-21) with ESMTP id NAA17836
	for <kernel-audit@nl.linux.org>; Fri, 25 Aug 2000 13:00:44 +1000
Date:   Fri, 25 Aug 2000 13:00:43 +1000 (EST)
From:   Tim Robbins <fyre@box3n.gumbynet.org>
To:     kernel-audit@nl.linux.org
Subject: Re: false asumption or security flaw? (fwd)
In-Reply-To: <Pine.LNX.3.96.1000824101058.10826C-100000@puspa.cs.ui.ac.id>
Message-ID: <Pine.LNX.4.21.0008251247090.17796-100000@box3n.gumbynet.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

On Thu, 24 Aug 2000, johan '97 wrote:

> so, in other words
> the function malloc gets it's memory from an already allocated memory (by the 
> kernel to the process) and hands it to the program to be used.
> once this chunk of memory is freed by the program, it is (probably?) still
> a part of the memory that is allocated to the process by the kernel.
> The kernel 'knows' that this chunk is still in use by the process,
> but the program 'thinks' differently. Hence, the probability of a chaos
> to happen is limited only in the process and not the kernel.
> 
> in a nut shell, it's more of the compilers inability to detect these sort
> of situation than a flaw in the kernel security.
> 
> is this correct?

Right. On Linux, the userland process resizes its data segment with the
brk() system call. The kernel knows this memory belongs to the process. It
can then later reduce the size of its data segment thus giving some memory
back for other processes to use. It's not a kernel flaw or a compiler flaw
really, just a weakness of C. Pointers allow you to do some great things,
but if you use them incorrectly you're bound to break something. 

Ugh. I think I've contributed enough to this thread.

Tim

--
Tim Robbins
fyre@box3n.gumbynet.org

..  Now KEN and BARBIE are PERMANENTLY ADDICTED to MIND-ALTERING DRUGS..
                            - Zippy the pinhead



Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Sat Aug 26 22:32:55 2000
Received: by humbolt.nl.linux.org id <S92318AbQHZUbh>;
	Sat, 26 Aug 2000 22:31:37 +0200
Received: from s2.surfeu.at ([212.197.128.38]:60331 "EHLO s2.surfeu.at")
	by humbolt.nl.linux.org with ESMTP id <S92316AbQHZUbN>;
	Sat, 26 Aug 2000 22:31:13 +0200
Received: from s2 (s2 [212.197.128.38])
	by s2.surfeu.at (8.9.3+Sun/8.9.1) with SMTP id WAA04847
	for <kernel-audit@nl.linux.org>; Sat, 26 Aug 2000 22:31:11 +0200 (MET DST)
Message-Id: <200008262031.WAA04847@s2.surfeu.at>
Date:   Sat, 26 Aug 2000 22:31:11 +0200 (MET DST)
From:   puma <puma@surfeu.com>
Reply-To: puma <puma@surfeu.com>
Subject:  Please remove me from this list
To:     kernel-audit@nl.linux.org
MIME-Version: 1.0
Content-Type: TEXT/plain; charset=us-ascii
Content-MD5: DOFfXb8/JTUNAnwNM6KyEg==
X-Mailer: dtmail 1.3.0 @(#)CDE Version 1.3.5 SunOS 5.7 sun4u sparc 
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

Thanks


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/

From owner-kernel-audit@nl.linux.org Mon Aug 28 00:43:13 2000
Received: by humbolt.nl.linux.org id <S92270AbQH0Wl5>;
	Mon, 28 Aug 2000 00:41:57 +0200
Received: from talos.forthnet.gr ([193.92.150.21]:11530 "EHLO forthnet.gr")
	by humbolt.nl.linux.org with ESMTP id <S92269AbQH0WlW>;
	Mon, 28 Aug 2000 00:41:22 +0200
Received: from gripen (ppp2089.ath.forthnet.gr [212.251.58.194])
	by forthnet.gr (8.8.8/8.8.5) with SMTP id BAA21314
	for <kernel-audit@nl.linux.org>; Mon, 28 Aug 2000 01:41:15 +0300
Message-ID: <003301c01077$d9dbfec0$bfbbfea9@gripen>
From:   "Manos Kanellopoulos" <mkanell@ath.forthnet.gr>
To:     <kernel-audit@nl.linux.org>
Subject: Please remove me from this list
Date:   Mon, 28 Aug 2000 01:40:48 +0300
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_0030_01C01090.FDCA4300"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.00.2615.200
X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2615.200
Sender: owner-kernel-audit@nl.linux.org
Precedence: bulk
Return-Path: <owner-kernel-audit@nl.linux.org>
X-Orcpt: rfc822;kernel-audit-list

This is a multi-part message in MIME format.

------=_NextPart_000_0030_01C01090.FDCA4300
Content-Type: text/plain;
	charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable

Thanks


------=_NextPart_000_0030_01C01090.FDCA4300
Content-Type: text/html;
	charset="iso-8859-7"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-7" =
http-equiv=3DContent-Type>
<META content=3D"MSHTML 5.00.2614.3500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>Thanks<BR></FONT></DIV></BODY></HTML>

------=_NextPart_000_0030_01C01090.FDCA4300--


Kernel-audit:  discussion list for security and the linux kernel
Archive:       http://mail.nl.linux.org/kernel-audit/