linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* Re: The disappearing sys_call_table export.
@ 2003-05-09 17:07 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09 17:07 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel

Christoph Hellwig wrote:

> >   What keeps users from opening files before the upper layer
> > filesystems get mounted?
>
> Nothing.  Why would we want to do such silly things?

  If I installed a virus scanner I would hope it could do that, otherwise
I might screw up and forget to set up all the layering just once and
get infected.  If I can tell it "protect all local filesystems" then
I can forget about it from then on.



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-16 16:15 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-16 16:15 UTC (permalink / raw)
  To: Mike Touloumtzis; +Cc: Ahmed Masud, Jesse Pollard, linux-kernel, Yoav Weiss

Mike Touloumtzis wrote:

> No Unix (even a "secure" one) is designed to run all security-critical
> code in the kernel.  That would be a bad design anyway, since it would
> run lots of code at an unwarranted privilege level.  "login" is not
> part of the kernel.  "su" is not part of the kernel".

  Yes, but "elsewhere" I can audit the system and see which programs
and subsystems are authorized to logon users and the authentication
methods they can use.  Note that the below output is not from some
"security enhanced" or "server" version of the OS but rather from
a $179 upgrade I bought at the local Staples store:


2003-05-16      05:06:25        Security        Success Audit   System Event    515     NT AUTHORITY\SYSTEM
"A trusted logon process has registered with the Local Security Authority.
 This logon process will be trusted to submit logon requests. 
 Logon Process Name:    Protected Storage Service "

2003-05-16      05:06:24        Security        Success Audit   System Event    515     NT AUTHORITY\SYSTEM
"A trusted logon process has registered with the Local Security Authority.
 This logon process will be trusted to submit logon requests. 
 Logon Process Name:    LAN Manager Workstation Service "

2003-05-16      05:06:17        Security        Success Audit   System Event    518     NT AUTHORITY\SYSTEM
"An notification package has been loaded by the Security Account Manager.
 This package will be notified of any account or password changes. 
 Notification Package Name:     scecli "

2003-05-16      05:06:17        Security        Success Audit   System Event    515     NT AUTHORITY\SYSTEM
"A trusted logon process has registered with the Local Security Authority.
 This logon process will be trusted to submit logon requests. 
 Logon Process Name:    Service Control Manager "

2003-05-16      05:06:17        Security        Success Audit   System Event    515     NT AUTHORITY\SYSTEM
"A trusted logon process has registered with the Local Security Authority.
 This logon process will be trusted to submit logon requests. 
 Logon Process Name:    Winlogon\MSGina "

2003-05-16      05:06:17        Security        Success Audit   System Event    515     NT AUTHORITY\SYSTEM
"A trusted logon process has registered with the Local Security Authority.
 This logon process will be trusted to submit logon requests. 
 Logon Process Name:    KSecDD "

2003-05-16      05:06:17        Security        Success Audit   System Event    514     NT AUTHORITY\SYSTEM
"An authentication package has been loaded by the Local Security Authority.
 This authentication package will be used to authenticate logon attempts. 
 Authentication Package Name:   D:\WINNT\system32\msv1_0.dll : MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 "

2003-05-16      05:06:17        Security        Success Audit   System Event    514     NT AUTHORITY\SYSTEM
"An authentication package has been loaded by the Local Security Authority.
 This authentication package will be used to authenticate logon attempts. 
 Authentication Package Name:   D:\WINNT\system32\schannel.dll : Microsoft Unified Security Protocol Provider "

2003-05-16      05:06:17        Security        Success Audit   System Event    514     NT AUTHORITY\SYSTEM
"An authentication package has been loaded by the Local Security Authority.
 This authentication package will be used to authenticate logon attempts. 
 Authentication Package Name:   D:\WINNT\system32\msv1_0.dll : NTLM "

2003-05-16      05:06:17        Security        Success Audit   System Event    514     NT AUTHORITY\SYSTEM
"An authentication package has been loaded by the Local Security Authority.
 This authentication package will be used to authenticate logon attempts. 
 Authentication Package Name:   D:\WINNT\system32\kerberos.dll : Kerberos "

2003-05-16      05:06:17        Security        Success Audit   System Event    514     NT AUTHORITY\SYSTEM
"An authentication package has been loaded by the Local Security Authority.
 This authentication package will be used to authenticate logon attempts. 
 Authentication Package Name:   D:\WINNT\system32\LSASRV.dll : Negotiate "



^ permalink raw reply	[flat|nested] 207+ messages in thread
* RE: The disappearing sys_call_table export.
@ 2003-05-15  8:16 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-15  8:16 UTC (permalink / raw)
  To: David Schwartz; +Cc: linux-kernel

David Schwartz wrote:

>>   So I think Linux needs these 'fringe' features if it's going to
>> continue to expand its user base in the face of such stupidity.
>
>       I, for one, completely disagree in the strongest way possible. This whole
> argument style rings entirely hollow with me. I'd much rather say, "We don't
> do that because it's stupid. We will gladly explain to you why we think it's
> stupid, what you really want, and how to get that from us."
>
>       Deliberately designing in misfeatures so that dumb people will get what
> they think they want is architectural suicide. I hope Linux never moves in
> that direction.

  Don't get me wrong -- I don't think high-security options are misfeatures.

  I'm just trying to say that such options, even if only rarely used,
are critical to gaining wide acceptance.  Just because dumb people require
them on their standard OS doesn't mean the features themselves are stupid...



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-14 23:24 Chuck Ebbert
  2003-05-15  0:49 ` David Schwartz
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-14 23:24 UTC (permalink / raw)
  To: Chris Siebenmann; +Cc: linux-kernel

Chris Siebenmann wrote:

> |   The people who used to require that still have lists of approved
> | operating systems.  Linux is not on that list.
> 
> To be blunt: and?
> Linux is not and never will be all things to all people. (Some of that
> can be seen in the ongoing discussions over, eg, LSM.)
>  There are many features that have far too small a target market to be
> of interest in mainline Unix.

  Large organizations like to standardize things wherever possible.

  Given an OS that is well suited for a fairly secure environment
that also runs widely-available office software, they will adopt it
for both uses, thus locking out other operating systems.

  Many of these decisions are made by Dumb White Guys sitting around
a boardroom table looking at feature lists, and pushed by even dumber
3-letter consulting firms whose technical representatives say things
like "Yes, we will be decrypting all SSL sessions at the firewall to
check for viruses."

  So I think Linux needs these 'fringe' features if it's going to
continue to expand its user base in the face of such stupidity.



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-14  8:41 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-14  8:41 UTC (permalink / raw)
  To: Jesse Pollard; +Cc: Linux Kernel Mailing List

Jesse Pollard wrote:

>>   "No audit trail" pretty much kills it right from the get-go.
>
> It does have audit trails... you do have to turn on process accounting. Are
> they pretty... no. But it is equivalent to base Solaris (well, before 2). You
> also have to turn on logs from every service daemon.

  It's almost there but not quite... but there is hope. :)



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-13 14:45 Chuck Ebbert
  2003-05-13 19:00 ` jjs
  2003-05-13 21:44 ` Jesse Pollard
  0 siblings, 2 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-13 14:45 UTC (permalink / raw)
  To: Jesse Pollard, Alan Cox; +Cc: Linux Kernel Mailing List

Jesse Pollard wrote:

> No - C2 evaluation has not been done for almost 3 years. That makes it
> impossible to get a C2 evaluation.

  The people who used to require that still have lists of approved
operating systems.  Linux is not on that list.

> And
> "C2 like capability" Linux does just as well as M$. Are the log files as
> pretty as would be desired? No. But they are acceptable for all US usage
> where a UNIX system is acceptable.

  "No audit trail" pretty much kills it right from the get-go.

  Base Solaris has it.  And I'm pretty sure HP-UX 9 did but that was
a while ago...

  And real ACLs are only now getting into Linux... how long till someone
certifies that they work is anyone's guess.

> These are also the same people that will not (or should not) accept
> laptops in their environement.

  Untrusted users shouldn't be allowed cellphones, PDAs, laptops or
similar.

  Next step up is probably full body cavity search to make sure you
haven't hidden a Microdrive somehwere...

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-13 14:45 Chuck Ebbert
  2003-05-13 21:32 ` Jesse Pollard
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-13 14:45 UTC (permalink / raw)
  To: Jesse Pollard, Yoav Weiss; +Cc: linux-kernel, alan

Jesse Pollard wrote:

> > However, it'll just give you false sense of security.  First of all, its
> > hardware dependent.  Second, it won't get wipe in case of a crash (which
> > is likely to happen when They come to take your disk).
>
> It is also not a valid wipe either.
> 
> This particular object reuse assumes the hardware is in a secured area. If it
> is in a secured area then you don't need to wipe it. It remains completely 
> under the systems control (even during a crash and reboot). The interval 
> between crash and reboot is covered by the requirement to be in a secured 
> area.

  ...until the admin walks in, shuts down the system, puts it on a cart
and hauls it out the door.  Is he going to wipe the swap area before he
does that?  Sure, you can write a procedure that says that's what he does
but he will not follow it (been there done that.)



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-13 13:58 Yoav Weiss
  2003-05-13 22:51 ` Ahmed Masud
  0 siblings, 1 reply; 207+ messages in thread
From: Yoav Weiss @ 2003-05-13 13:58 UTC (permalink / raw)
  To: masud; +Cc: linux-kernel

Masud wrote:

> But isn't swap crypting fun ? :-) Running encrypted swap is okay so long
> as we throw away the key after each session.  This can be easily (famous
> last words) achieved under crypto kernels. I am not certain if such
> functionaility is being contemplated for the Linux kernel along with the
> new cryptoloop stuff, if there isn't i can volunteer to put something
> like that in - if we are interested. Are we?

See http://loop-aes.sourceforge.net/
The README already explains how to use it as encrypted swap.  I've been
using it for quite a while without problems.

If you feel like volunteering for an encrypted swap, I suggest the model
used by OpenBSD.  Instead of using an encrypted swap dev with one random
key, they seem to have a per-process key and encrypt swap areas of the
process with its key.  When a process dies, its key dies with it, so the
swap space it used is considered clean without having to wait for an
override or a reboot.

Another fun project is encrypted hibernation (suspend-to-disk).  Once the
kernel contains a stable hibernation option, I'm certainly going to
encrypt it.



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-13  9:52 Chuck Ebbert
  2003-05-13 13:32 ` Yoav Weiss
  2003-05-14  7:44 ` Mike Touloumtzis
  0 siblings, 2 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-13  9:52 UTC (permalink / raw)
  To: Yoav Weiss; +Cc: linux-kernel

> cat >/sbin/swapoff
> #!/bin/sh
> /sbin/swapoff.real
> /sbin/wipeswap
> ^D
> chmod +x /sbin/swapoff

  OK...

 # rpm --freshen mount-2.11n-12.rpm


   swapoff get silently replaced AFAICT.

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-13  1:57 Chuck Ebbert
  2003-05-13 12:24 ` Jesse Pollard
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-13  1:57 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux Kernel Mailing List

Alan Cox wrote:

> 1. Base Linux is not C2 certified

  That could be fixed... (right?)  Filesystems returning data past the
end of what the user wrote might be a big problem though -- this must
be guaranteed even in obscure corner cases.

> 2. C2 is obsolete

  Obsolete or not, it is mandatory for some people.  No check box,
no purchase order (or no certificate of operation.)

> 3. NSA SELinux can do the needed stuff from scanning the code

  But will it get merged?

> 4. Even then data erasure is not guaranteed because of the drive logic

  People who really care require the drive be reduced to pieces small
enough to fit through a sieve with ~2mm holes in it before it leaves
their sight.  For the rest, overwrite of the swap data is a useful if
not 100% reliable step to take.  Legitimate users with servers locked
up in secure areas don't really worry about someone unplugging the box
and walking away with it either.



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-13  1:57 Chuck Ebbert
  2003-05-13  2:25 ` Yoav Weiss
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-13  1:57 UTC (permalink / raw)
  To: Yoav Weiss; +Cc: linux-kernel

Yoav Weiss wrote:

>>   "That can be done manually" does not get you the check mark in
>> the list of features.  Management wants idiot-resistant security.
>
> It has nothing to do with idiot-resistance.  Why should this multi-write
> operation be done in kernel ?  mkswap is a usermode program.  mkfs is a
> usermode program.  If you want to have a wipeswap script that copies a
> chunk of your /dev/zero to the swap, it should also be in usermode.  Just
> run it in wherever rc file you use to swapoff.

  And when I type 'swapoff' at the command line the whole scheme fails
unless I am a perfect robot sysadmin and always remember to wipe the
file.  This needs to 'fail safe' and it needs to be done within the kernel
to be considered a working feature.

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-12 22:57 Yoav Weiss
  2003-05-12 23:58 ` Bryan Andersen
  2003-05-13 12:11 ` Jesse Pollard
  0 siblings, 2 replies; 207+ messages in thread
From: Yoav Weiss @ 2003-05-12 22:57 UTC (permalink / raw)
  To: 76306.1226; +Cc: alan, linux-kernel

On Mon, 12 May 2003 17:51:25 EDT, Chuck Ebbert said:

> > man dd ?
>
>   "That can be done manually" does not get you the check mark in
> the list of features.  Management wants idiot-resistant security.

It has nothing to do with idiot-resistance.  Why should this multi-write
operation be done in kernel ?  mkswap is a usermode program.  mkfs is a
usermode program.  If you want to have a wipeswap script that copies a
chunk of your /dev/zero to the swap, it should also be in usermode.  Just
run it in wherever rc file you use to swapoff.

However, it'll just give you false sense of security.  First of all, its
hardware dependent.  Second, it won't get wipe in case of a crash (which
is likely to happen when They come to take your disk).

Until linux gets a real encrypted swap (the kind OpenBSD implements), you
can settle for encrypting your whole swap with one random key that gets
lost on reboot.  Encrypted loop dev with a key from /dev/random easily
gives you that.

Download the latest loop-AES from http://loop-aes.sourceforge.net/ and
follow the "Encrypting swap on 2.4 kernels" section in README.



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-12 21:51 Chuck Ebbert
  2003-05-12 21:05 ` Alan Cox
  2003-05-12 22:12 ` Valdis.Kletnieks
  0 siblings, 2 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-12 21:51 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

Alan Cox wrote:

>>   ...and on a related topic, if someone wrote a patch to optionally clear
>> the swap area at swapoff would it ever be accepted?
>
> man dd ?

  "That can be done manually" does not get you the check mark in
the list of features.  Management wants idiot-resistant security.

^ permalink raw reply	[flat|nested] 207+ messages in thread
[parent not found: <20030512164017$6c09@gated-at.bofh.it>]
* Re: The disappearing sys_call_table export.
@ 2003-05-12 16:32 Chuck Ebbert
  2003-05-12 16:46 ` Alan Cox
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-12 16:32 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux Kernel Mailing List

Alan Cox wrote:

> You knocked down my military server - who cares. You stole my
> list of secret command centres - Im deeply upset.

  Or even worse: you stole my list of command centers and I don't
even know it happened.  At least with an audit trail you have a
chance of knowing your secrets have been compromised.

  Banks also seem to like the idea of a server that will crash
rather than transfer funds without leaving a trail.

  So how long till Linux gets decent auditing?  Is the SNARE code going
to get into the kernel?

  ...and on a related topic, if someone wrote a patch to optionally clear
the swap area at swapoff would it ever be accepted?

^ permalink raw reply	[flat|nested] 207+ messages in thread
[parent not found: <20030511164010$5d34@gated-at.bofh.it>]
* Re: The disappearing sys_call_table export.
@ 2003-05-11 20:39 Chuck Ebbert
  2003-05-11 22:32 ` Yoav Weiss
  2003-05-11 22:32 ` Ahmed Masud
  0 siblings, 2 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-11 20:39 UTC (permalink / raw)
  To: Yoav Weiss; +Cc: Linux Kernel Mailing List, Terje Eggestad, Ahmed Masud, arjanv

Yoav Weiss wrote:

> No one specified what audit_log does in this case.  Usually, in such
> modules, the audit function doesn't just log everything.  It can, for
> example, rate-limit the logging and just spit a message about the user
> DoSing the log system.

  Not on the systems I've seen.  Max log file size is 4GB and the
logs are on their own partition.  If the file fills up the system
crashes immediately and only administrators can log in after reboot
until the logs are archived.

> The usermode code can change it and
> change it back as soon as the file has been unlinked.  If the system is
> under heavy load (generated by the attacker), the attacking process is
> reniced to 20, and the monitoring part of it has higher priority and keeps
> stat(2)ing the file, a thread in the attack code may actually be able to
> change the filename back in time for the second check.

  Yes, but now any unsuccessful attempts to change the name will be
logged, where before there was basically no risk for the attacker
trying over and over until success.  Even a single failure could
raise an alert on the target machine, something a cracker definitely
does not want to happen.

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-11 16:32 Chuck Ebbert
  2003-05-11 17:20 ` David Wagner
  2003-05-11 17:53 ` Yoav Weiss
  0 siblings, 2 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-11 16:32 UTC (permalink / raw)
  To: arjanv; +Cc: Ahmed Masud, Yoav Weiss, Terje Eggestad, Linux Kernel Mailing List

arjanv wrote:

> examle: pseudocode for the unlink syscall
> 
> long your_wrapped_syscall(char *userfilename)
> {
>     char kernelpointer[something];
>     copy_from_user(kernelpointer, usefilename, ...);
>     audit_log(kernelpointer);
>     return original_syscall(userfilename);
> }


  That code has another hole that nobody else has mentioned
yet: I can fill the audit log by trying to delete nonexistent files,
and if accused of trying to mount a DOS attack on the audit trail
I can reasonably claim that it was all an accident...

  How about:

long wrapped_unlink(char *userfilename)
{
        char name1[len], name2[len];
        long ret;

        copy_from_user(name1, userfilename, ...);
        ret = original_unlink(userfilename);
        copy_from_user(name2, userfilename, ...);

        if (strncmp(name1, name2, len))
                audit_log(name1, name2, UNLINK_NAME_CHANGED);
        if (ret == 0 && AUDIT_SUCCESS)
                audit_log(name1, name2, UNLINK_SUCCEEDED);
        if (ret == -EPERM && AUDIT_FAILURE)
                audit_log(name1, name2, UNLINK_FAILED);

        return ret;
}

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-10 21:45 Yoav Weiss
  0 siblings, 0 replies; 207+ messages in thread
From: Yoav Weiss @ 2003-05-10 21:45 UTC (permalink / raw)
  To: daw; +Cc: linux-kernel

> Let's see you do sys_execve()...  sys_socketcall() and sys_ioctl() are
> fun, too.  (And, I worry about doubly-indirected pointers, for instance.)
> It's probably do-able, but you'd better stock up on the Advil in advance:
> we're in major headache country, folks.

I agree.  I could post my 2.0.x code for doing this, but it would be
counter-productive since security apps should use LSM for this very
reason.  I was merely suggesting a way for Masud to solve his specific
problem without rewriting his module.

sys_execve() and sys_socketcall() are actually not that hard.  sys_ioctl()
is next to impossible because no never know what the structs look like.
Luckily, most security apps don't require ioctl-screening.

Most security applications should use LSM but its not a good reason to
remove sys_call_table, since its still useful for many non-security
purposes.

	Yoav Weiss


^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-10 19:32 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-10 19:32 UTC (permalink / raw)
  To: arjanv
  Cc: Ahmed Masud, Terje Eggestad, Linux Kernel Mailing List, viro,
	Jesse Pollard, Alan Cox

Arjan van de Ven wrote:

> I'm pretty sure that auditing by your module can easily be avoided.
>
> examle: pseudocode for the unlink syscall
>
> long your_wrapped_syscall(char *userfilename)
> {
>     char kernelpointer[something];
>     copy_from_user(kernelpointer, usefilename, ...);
>     audit_log(kernelpointer);
>     return original_syscall(userfilename);
> }

  Great, now how do you plan to get that code loaded into memory on
my configuration? (no modules, /dev/kmem unwriteable) (or ipd driver
loaded on NT/2K)

> The only solution for this is to check/audit/log things after the ONE
> copy. Eg not by overriding the syscall but inside the syscall.

  If I can alter kernel memory I can patch out your auditing code.
It's just more difficult if you try to hide it inside the syscall.  :)



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-10 19:18 Yoav Weiss
  2003-05-10 19:53 ` Muli Ben-Yehuda
  2003-05-10 20:48 ` David Wagner
  0 siblings, 2 replies; 207+ messages in thread
From: Yoav Weiss @ 2003-05-10 19:18 UTC (permalink / raw)
  To: arjanv, masud; +Cc: linux-kernel

On 10 May 2003, Arjan van de Ven wrote:

> I'm pretty sure that auditing by your module can easily be avoided.
>
> examle: pseudocode for the unlink syscall
>
> long your_wrapped_syscall(char *userfilename)
> {
>     char kernelpointer[something];
>     copy_from_user(kernelpointer, usefilename, ...);
>     audit_log(kernelpointer);
>     return original_syscall(userfilename);
> }
>
> now.... the original syscall does ANOTHER copy_from_user().
> Eg I can easily fool your logging by having a second thread change the
> filename between the time your code copies it and the time the original
> syscall copies it again. The chances of getting the timing right are 50%
> at least (been there done that ;)
>
> The only solution for this is to check/audit/log things after the ONE
> copy. Eg not by overriding the syscall but inside the syscall.

been there done that, too :)

However, there is a solution.

Masud, your delay-based solutions won't work because an attack code can
just keep running in a loop until it gets the timing right.  Once is
enough.  Even if it could work, it would have impact on the whole system.
Afaik, you can't really yield the CPU for very short time slices so you'll
have to busy-loop instead, and its not acceptable.  I believe the below
solution is the right one.  Arjan, please correct me if I'm wrong.

The solution is to have only ONE REAL copy, done by the wrapper.  The
original syscall will copy from a kernel ptr, unknowingly.  Consider
the following modified pseudo-code:

long your_wrapped_syscall(char *userfilename)
{
    char kernelpointer[something];
    copy_from_user(kernelpointer, usefilename, ...);
    audit_log(kernelpointer);
    old_fs = get_fs();
    set_fs(KERNEL_DS);
    ret = original_syscall(kernelpointer);
    set_fs(old_fs);
    return ret;
}

userfilename is only copied once.  original_syscall just copies
kernelpointer again, to another kernel pointer.  No race.

Now, don't get me wrong - I still think intercepting the syscall is not
the right thing to do in this case, since LSM provides hooks in better
locations.  However, Masud has a working module that works this way, and
rewriting it for LSM is probably a headache.  No reason for him to rewrite
his module if it can be fixed as I suggested above.

Still, in my opinion, this symbol should remain exported, if only for test
modules like the one suggested by Muli.  I use them all the time.

Another thing to be considered is kernel newbies.  Most people, when
getting started in the kernel, do it by writing module.  One of the best
ways to understand certain parts of the kernel is to intercept some
syscalls and playing with them.  I gave some courses about it in the past,
and syscall intercepting was always a good exercise for newbies.  Face it,
most people can learn better by playing then by reading the code.

Removing this symbol will not really get in the way for the bad guys
because it'll always be possible to find and intercept it anyway (see my
previous post in this thread), but it'll increase the learning curve for
kernel newbies.  Do we really want that ?

	Yoav Weiss



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-09 21:22 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09 21:22 UTC (permalink / raw)
  To: root; +Cc: Valdis.Kletnieks, Linux Kernel Mailing List

Tinfoil Hat wrote:

> Microsoft installed Magic Lantern software within
> the kernel and within all software updates, (service Pack 2 of
> Win/2000/Prof as part of their deal with the Justice Department
> when our attention was diverted after 9/11.

 SP2 was released on 4 May 2001 and installed on this computer on
15 May 2001.  :)

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-09 17:07 Chuck Ebbert
  2003-05-09 18:27 ` Richard B. Johnson
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09 17:07 UTC (permalink / raw)
  To: Alan Cox; +Cc: Christoph Hellwig, Linux Kernel Mailing List

Alan Cox wrote:

>>   Security-sensitive upper layers like virus scanners and loggers
>> would want to do it that way.  The upper layer might even just log
>> the fact that mount happened and then stay out of the way after that.
>
> What makes you say that. If the administrator has full priviledges then
> its kind of irrelevant trying to force anything "for security reasons"

  Check out the NSA's guide for securing Win2k machines sometime.  They
go through all kinds of steps to separate auditing and administration
even though an administrator can get around them and play with the audit
trail anyway.  It raises the bar and removes the defense of plausible
deniability if an admin gets caught (he can hardly claim it was an
'accident' that he granted himself audit privileges and then used them
to tamper with the audit log.)

        1.  Create a new group: Auditors
        2.  Grant these rights to Auditors:
                Take ownership of files; Manage auditing
        3.  Create a new user: Auditor, and put it in these groups:
                Users; Auditors
        4.  Log on as Auditor and take ownership of
                %systemroot%\system32\config\SecEvent.Evt
        5.  Set permissions on that security logfile:
                a. System: full control
                b. Administrators: no access
                c. Auditors: full control
        6.  Now log on as an administrator and take away these rights:
                a. from Administrators: Manage auditing
                b. from Auditors: Take ownership of files
        7.  Enable these extra security options:
                a. crash on audit failure
                b. clear page file on shutdown
                c. full privilege auditing
                d. lots more...

After setting up auditing and ACLs (many pages of directions for that)
the audit duties are done by unprivileged users and administrators
cannot see or alter the audit trail.

  Seems like a lot of useless work given that the admins can grant
themselves any rights they want, doesn't it?

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-09 12:41 Chuck Ebbert
  2003-05-09 12:47 ` Christoph Hellwig
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09 12:41 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: Alan Cox, linux-kernel

Christoph Hellwig wrote:

> You can have multiple mountspoints with the same path, only
> the topmost one will be seen by userland.

  What keeps users from opening files before the upper layer
filesystems get mounted?  And how do you handle user-mountable
media like CD-ROMS?



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-09 11:09 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09 11:09 UTC (permalink / raw)
  To: Shachar Shemesh
  Cc: linux-kernel, Steffen Persvold, D.A.Fedorov, Alan Cox,
	Arjan van de Ven, Terje Eggestad

Shachar Shemesh wrote:

> I'm currently trying to work with some other subscribers of this list on 
> a design. Getting 1, 2 and 3 is a complicated enough task, of course. I 
> would like to hear estimates about inclusion chances should we manage to 
> come up with an implmentation that lives up to all the above.

 How many users would want to actually modify the syscall parameters
or change visible system behavior when a syscall happens?

 Maybe something like this would work?

  1.  You can register to be notified when a syscall occurs,
      either before or after or both.
  2.  The only action you can take must be 'private' (within
      your driver or subsystem.)



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-09  9:43 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09  9:43 UTC (permalink / raw)
  To: Terje Malmedal; +Cc: D.A.Fedorov, linux-kernel

Terje wrote:

> Is there any reasonable way to be able to do modify a running kernel
> like this? I assume I can't count on the method from Phrack working
> forever...

  The Phrack method involves following int 0x80 and then looking for
an instruction in the syscall code that points to the table. (Check the
archives for pt_fix.c that I posted about a month ago.)  Note that it's
trivial to break this too; I planned to post a patch to do just that
but never got around to it...



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-09  9:11 Chuck Ebbert
  2003-05-09 10:47 ` Christoph Hellwig
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09  9:11 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel, Alan Cox

>>   Does a layered filesystem get all requests for ext3 IO if it's above
>> it then, or does someone have to manually mount it for each volume?
>
> after you mounted it you get all I/O requests below the mountpoint.

  So it's not 'layer a filesystem over another one' it's 'mount an
instance of a filesystem over another instance' then.  And this means
it gets mounted twice with two different mountpoint names, right?



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-09  7:50 Chuck Ebbert
  2003-05-09  7:57 ` Christoph Hellwig
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09  7:50 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel

Christoph Hellwig wrote:

>>   So when I register my filesystem, can I indicate that I want to be
>> layered over top of the ext3 driver
>
> Yes.
>
>> and get control anytime someone
>> mounts an ext3 fileystem,
>
> no.

  Does a layered filesystem get all requests for ext3 IO if it's above
it then, or does someone have to manually mount it for each volume?

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-09  7:50 Chuck Ebbert
  2003-05-09  7:59 ` Christoph Hellwig
  2003-05-09 12:18 ` Alan Cox
  0 siblings, 2 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-09  7:50 UTC (permalink / raw)
  To: Alan Cox; +Cc: Linux Kernel Mailing List, Christoph Hellwig

Alan Cox wrote:

>>   So when I register my filesystem, can I indicate that I want to be
>> layered over top of the ext3 driver and get control anytime someone
>> mounts an ext3 fileystem, so I can decide whether the volume being
>> mounted is one that I want to intercept open/read/write requests for?
>
> That would assume you had a right to dictate that the administrator
> couldnt mount other file systems without your stacking.

  Security-sensitive upper layers like virus scanners and loggers
would want to do it that way.  The upper layer might even just log
the fact that mount happened and then stay out of the way after that.

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-08 19:43 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-08 19:43 UTC (permalink / raw)
  To: Alan Cox; +Cc: linux-kernel

> Userspace
>       --- ptrace

  Ptrace appears to be effectively broken on 2.4.21-rc -- I can't strace
child processes that fork even as root, anyway.


> Block Layer
>       Loadable disk driver (Which can be made to stack)

  I'm sorry but I've been looking at the md code for about six months
and the 'big picture' of how it's doing what it does escapes me.  The
code in md.c:lock_rdev(), for example -- looks like an incredibly deep
understanding of how all the block code works is needed to write a
driver like this.

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-08 19:43 Chuck Ebbert
  2003-05-08 19:58 ` Christoph Hellwig
  2003-05-09 13:53 ` Jesse Pollard
  0 siblings, 2 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-08 19:43 UTC (permalink / raw)
  To: Jesse Pollard; +Cc: linux-kernel

> Have you tried catching the display IO ???

  Not in a million years -- display drivers work by pure magic AFAIC.

> HSM has existed on UNIX based machines for a long time.

  Show me three HSM implementations for Linux and I'll show you three
different mechanisms. :)

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-08 19:43 Chuck Ebbert
  2003-05-08 19:48 ` Christoph Hellwig
  2003-05-08 21:44 ` Alan Cox
  0 siblings, 2 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-08 19:43 UTC (permalink / raw)
  To: Christoph Hellwig; +Cc: linux-kernel

> you can write a stackable filesystem on linux, too and intercept any
> I/O request.  You just have to do it through a sane interface, mount
> and not by patching the syscall table - which you can do under
> windows either.  (at least not as part of the public API).

  So when I register my filesystem, can I indicate that I want to be
layered over top of the ext3 driver and get control anytime someone
mounts an ext3 fileystem, so I can decide whether the volume being
mounted is one that I want to intercept open/read/write requests for?



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-08 14:08 Chuck Ebbert
  2003-05-08 14:36 ` Christoph Hellwig
                   ` (2 more replies)
  0 siblings, 3 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-08 14:08 UTC (permalink / raw)
  To: viro; +Cc: linux-kernel, Terje Eggestad

Al Viro wrote:

>> > I'd make a stab at it if I knew that it stood a chance of getting
>> > accepted. 
>> 
>> I dont think it has.
>
> I think it could, actually - who maintains fortunes these days?  It's
> a bit too long, though...

  Wow, Advanced Sarcasm.  Must be part of the Graduate program...

  Meanwhile on Win2k I can intercept any IO request by
wrting a filter driver, and that driver can get control on the way
back to userspace by registering a completion routine.  Such filters
can be arbitrarily chained together and can be placed either above or
below an FSD, making such things as virus detection, HSM and disk
mirroring much easier to write...

  How would I do this on Linux?  How would virus detection and HSM
coexist?  (HSM would have to be 'above' the virus detector, since it
makes no sense to try and scan a file that's been migrated until it
gets recalled back to disk.)

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-07 19:04 Chuck Ebbert
  2003-05-08  9:58 ` Terje Eggestad
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-07 19:04 UTC (permalink / raw)
  To: arjanv; +Cc: Steffen Persvold, linux-kernel

>> Preloading libraries, ptracing init, patching g/libc, etc. are
>> obviously not the way to go.
>
> those obviously need to be implemented via the security subsystem (eg
> LSM). Hooks are obviously the wrong level to do things and I could even
> tell you that you cannot implement this right from a module actually.

  What is really needed is some kind of proper generic hooking setup
that could be used both by LSM and other things.  People doing this
may need to intercept syscalls both on their way to the kernel and 
on the way back to userland (so they can see return codes.)  They may
also need to say whether they want to be first or last if there are
multiple users of this facility.

  But the real question is why the export of sys_call_table was so
gratuitously removed without any kind of replacement being offered.
And the attitude of the developers about it is truly awful. ("Oh, so
we broke the drivers you depend on for your livelihood?  You can just
go get a new job -- pounding sand down a rathole.")



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-07 15:34 petter wahlman
  2003-05-07 15:48 ` Arjan van de Ven
                   ` (2 more replies)
  0 siblings, 3 replies; 207+ messages in thread
From: petter wahlman @ 2003-05-07 15:34 UTC (permalink / raw)
  To: linux-kernel

 
It seems like nobody belives that there are any technically valid
reasons for hooking system calls, but how should e.g anti virus
on-access scanners intercept syscalls?
Preloading libraries, ptracing init, patching g/libc, etc. are
obviously not the way to go.


-p.



^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-06 20:48 Chuck Ebbert
  0 siblings, 0 replies; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-06 20:48 UTC (permalink / raw)
  To: David S. Miller; +Cc: linux-kernel, terje.eggestad

> You might have a derivative work after obtaining access to a
> non-exported interface.  If this is correct, binary-only modules
> can't do this and therefore they must stick to exported interfaces.

  And what about modules that just hook syscall directly by hooking int
0x80 or messing with sysenter?

^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-06 15:51 Yoav Weiss
  0 siblings, 0 replies; 207+ messages in thread
From: Yoav Weiss @ 2003-05-06 15:51 UTC (permalink / raw)
  To: davem; +Cc: linux-kernel

> You might have a derivative work after obtaining access to a
> non-exported interface.  If this is correct, binary-only modules
> can't do this and therefore they must stick to exported interfaces.

Thats an interesting question.  Who violates the license here ?  It can't
be the author of the binary driver (unless it was in breach before the
symbol was unexported).  Thats because it didn't change.  The user,
wishing to keep using his driver although the kernel changed and broke it,
generates and insmod's a module that re-exports a symbol that the module
relies upon.  However, the user didn't release any code so he can't be in
breach either.

Its just a method backwards compatibility of kernel modules.  Of course,
IANAL, so I may be wrong here.

One could argue that the binary module was in breach in the first place,
because of various reasons.  My point is that the re-exporting module
didn't change anything in terms of derived work.

	Yoav Weiss


^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-06  8:45 Yoav Weiss
  2003-05-06  9:15 ` David S. Miller
                   ` (2 more replies)
  0 siblings, 3 replies; 207+ messages in thread
From: Yoav Weiss @ 2003-05-06  8:45 UTC (permalink / raw)
  To: D.A.Fedorov, terje.eggestad, 76306.1226; +Cc: linux-kernel

> But how? When some global will not be exported, it would not be listed
> in /proc/ksyms.

So what ?
You just find the right address (in this case by getting the addresses of
exported syscalls and finding a list in memory, containing them in the
right order), and cast it to be the syscall table.  If you want it to work
with a binary-only driver, you can even insmod a small module that does
that and adds the result to the symbol table for other modules to use.

We've been doing that for years on closed-source systems like AIX.  The
above is just one way to locate a struct in memory.  A faster way is to
find some exported structs which are known to point to the unexported
symbol from some offset, extract the symbol's address, and "re-export" it.

In fact, in linux which is opensource, you can probably write a script
that extracts any unexported symbol from the source code, find a path to
it from some exported symbol, and automagically create a module that
re-exports this symbol for your legacy driver to use.

If you write the script, don't forget to GPL it :)

	Yoav Weiss


^ permalink raw reply	[flat|nested] 207+ messages in thread
* Re: The disappearing sys_call_table export.
@ 2003-05-05 21:29 Chuck Ebbert
  2003-05-05 22:49 ` Terje Eggestad
  0 siblings, 1 reply; 207+ messages in thread
From: Chuck Ebbert @ 2003-05-05 21:29 UTC (permalink / raw)
  To: Terje Eggestad; +Cc: linux-kernel

> Lets deal, I'll GPL the trace module if you get me a 
> EXPORT_SYMBOL_GPL(sys_call_table);

 You could always use the rootkit techniques from Phrack 58 to find
the table... seems kind of silly to do that in kernel mode, but it
should work.

^ permalink raw reply	[flat|nested] 207+ messages in thread
[parent not found: <mailman.1052142720.4060.linux-kernel2news@redhat.com>]
* Re: The disappearing sys_call_table export.
@ 2003-05-05 13:30 Dmitry A. Fedorov
  2003-05-05 13:42 ` Christoph Hellwig
  2003-05-05 13:45 ` viro
  0 siblings, 2 replies; 207+ messages in thread
From: Dmitry A. Fedorov @ 2003-05-05 13:30 UTC (permalink / raw)
  To: Arjan van de Ven, Christoph Hellwig; +Cc: linux-kernel


On Mon, May 05, 2003 at 04:01:25PM +0700, Dmitry A. Fedorov wrote:
>> But why module should not have ability to call any function which is
>> available from user space?

>> Almost all of my third-party drivers are broken by this.
>> What is worse, redhat "backported" this "feature" to their 2.4
>> patched kernels and now I should distinguish 2.4 and "redhat 2.4"
>> in my compatibility headers.

From: Arjan van de Ven <arjanv@redhat.com>
> that's you you can just call sys_read() and co directly.

Yes, for redhat kernels - almost all of sys_* functions are exported.
And there is kernel.org's one with only few sys_* exported.
And how I will distinguish redhat's kernel from other ones? - there is
no something like #define REDHAT_PATCHED in headers.
I don't want to have separate driver source version
for each of incompatible kernel variant, I prefer to have single
driver source which is adapted to user's environment at compilation
time.

From: Christoph Hellwig <hch@infradead.org>
> What about just fixing your drivers instead of moaning?  If you
> submit a pointer to your driver source and explain what you want to
> do someone might even help you..

Of course, I will fix my drivers (permanent kernel changes
provides us maintainence job forever :).

For example:

http://www.rtdusa.com/software/RTDFinland/ECAN_Linux.zip
http://www.rtdusa.com/software/RTDFinland/UPS25_Linux.ZIP

I use the following calls:

sys_mknod
sys_chown
sys_umask
sys_unlink

for creating/deleting /dev entries dynamically on driver
loading/unloading. It allows me to acquire dynamic major
number without devfs and external utility of any kind.
And there is no risk of intersection with statically assigned major
numbers, as it is for many others third-party sources.

It works long time for any kernels from 2.0 to 2.4 (except the last
redhat's 2.4) and it should works with 2.6, I hope.


I use sys_write to output loading/device detection/diagnostic
messages to process's stderr when appropriate. Yes, it may look as
"wrong thing" but it uses only legal kernel mechanisms and it saves
lots of time with e-mail support:
/sbin/insmod driver verbose=1 2>&1 | mail -s 'it does not works' me@


It would be nice if either sys_call_table left exported and placed in
read-only data section to prevent modification (do you want just that?)
or _all_ of sys_* function would be exported in original kernel.


^ permalink raw reply	[flat|nested] 207+ messages in thread
* The disappearing sys_call_table export.
@ 2003-05-05  8:19 Terje Eggestad
  2003-05-05  8:23 ` Christoph Hellwig
                   ` (2 more replies)
  0 siblings, 3 replies; 207+ messages in thread
From: Terje Eggestad @ 2003-05-05  8:19 UTC (permalink / raw)
  To: linux-kernel

Now that it seem that all are in agreement that the sys_call_table
symbol shall not be exported to modules, are there any work in progress
to allow modules to get an event/notification whenever a specific
syscall is being called?

We have a specific need to trace mmap() and sbrk() calls. 



-- 
_________________________________________________________________________

Terje Eggestad                  mailto:terje.eggestad@scali.no
Scali Scalable Linux Systems    http://www.scali.com

Olaf Helsets Vei 6              tel:    +47 22 62 89 61 (OFFICE)
P.O.Box 150, Oppsal                     +47 975 31 574  (MOBILE)
N-0619 Oslo                     fax:    +47 22 62 89 51
NORWAY            
_________________________________________________________________________


^ permalink raw reply	[flat|nested] 207+ messages in thread

end of thread, other threads:[~2003-06-15 22:23 UTC | newest]

Thread overview: 207+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-05-09 17:07 The disappearing sys_call_table export Chuck Ebbert
  -- strict thread matches above, loose matches on Subject: below --
2003-05-16 16:15 Chuck Ebbert
2003-05-15  8:16 Chuck Ebbert
2003-05-14 23:24 Chuck Ebbert
2003-05-15  0:49 ` David Schwartz
2003-05-14  8:41 Chuck Ebbert
2003-05-13 14:45 Chuck Ebbert
2003-05-13 19:00 ` jjs
2003-05-13 21:44 ` Jesse Pollard
2003-05-13 14:45 Chuck Ebbert
2003-05-13 21:32 ` Jesse Pollard
2003-05-13 13:58 Yoav Weiss
2003-05-13 22:51 ` Ahmed Masud
2003-05-13 23:58   ` Yoav Weiss
2003-06-12 23:20     ` Nigel Cunningham
2003-06-15 22:37       ` Yoav Weiss
2003-05-13  9:52 Chuck Ebbert
2003-05-13 13:32 ` Yoav Weiss
2003-05-14  7:44 ` Mike Touloumtzis
2003-05-14 10:34   ` Ahmed Masud
2003-05-14 20:58     ` Mike Touloumtzis
2003-05-14 21:32       ` Richard B. Johnson
2003-05-14 21:37         ` Yoav Weiss
2003-05-14 21:51           ` Richard B. Johnson
2003-05-15 13:17         ` Jesse Pollard
2003-05-15 15:16           ` Chris Ricker
2003-05-15 15:31             ` Richard B. Johnson
2003-05-15 15:33               ` Chris Ricker
2003-05-15 15:46                 ` Richard B. Johnson
2003-05-15 16:21                   ` Ahmed Masud
2003-05-15  2:06       ` Ahmed Masud
2003-05-13  1:57 Chuck Ebbert
2003-05-13 12:24 ` Jesse Pollard
2003-05-13  1:57 Chuck Ebbert
2003-05-13  2:25 ` Yoav Weiss
2003-05-12 22:57 Yoav Weiss
2003-05-12 23:58 ` Bryan Andersen
2003-05-13 12:11 ` Jesse Pollard
2003-05-13 13:44   ` Yoav Weiss
2003-05-13 21:26     ` Jesse Pollard
2003-05-13 22:21       ` Yoav Weiss
2003-05-14 13:05         ` Jesse Pollard
2003-05-12 21:51 Chuck Ebbert
2003-05-12 21:05 ` Alan Cox
2003-05-12 22:12 ` Valdis.Kletnieks
2003-05-12 21:19   ` Alan Cox
2003-05-12 22:29     ` Valdis.Kletnieks
2003-05-13 12:31     ` Ahmed Masud
     [not found] <20030512164017$6c09@gated-at.bofh.it>
2003-05-12 17:02 ` Pascal Schmidt
2003-05-12 16:32 Chuck Ebbert
2003-05-12 16:46 ` Alan Cox
     [not found] <20030511164010$5d34@gated-at.bofh.it>
2003-05-12  0:47 ` Ben Pfaff
2003-05-11 20:39 Chuck Ebbert
2003-05-11 22:32 ` Yoav Weiss
2003-05-11 21:46   ` Alan Cox
2003-05-11 22:57     ` David Schwartz
2003-05-14 21:08       ` H. Peter Anvin
2003-05-11 23:22     ` Yoav Weiss
2003-05-11 22:32 ` Ahmed Masud
2003-05-11 16:32 Chuck Ebbert
2003-05-11 17:20 ` David Wagner
2003-05-11 17:53 ` Yoav Weiss
2003-05-10 21:45 Yoav Weiss
2003-05-10 19:32 Chuck Ebbert
2003-05-10 19:18 Yoav Weiss
2003-05-10 19:53 ` Muli Ben-Yehuda
2003-05-10 20:06   ` Yoav Weiss
2003-05-11  3:54     ` Ahmed Masud
2003-05-10 20:48 ` David Wagner
2003-05-09 21:22 Chuck Ebbert
2003-05-09 17:07 Chuck Ebbert
2003-05-09 18:27 ` Richard B. Johnson
2003-05-09 19:02   ` Valdis.Kletnieks
2003-05-09 19:18     ` Richard B. Johnson
2003-05-09 19:25       ` Valdis.Kletnieks
2003-05-09 12:41 Chuck Ebbert
2003-05-09 12:47 ` Christoph Hellwig
2003-05-09 11:09 Chuck Ebbert
2003-05-09  9:43 Chuck Ebbert
2003-05-09  9:11 Chuck Ebbert
2003-05-09 10:47 ` Christoph Hellwig
2003-05-09  7:50 Chuck Ebbert
2003-05-09  7:57 ` Christoph Hellwig
2003-05-09  7:50 Chuck Ebbert
2003-05-09  7:59 ` Christoph Hellwig
2003-05-09 12:18 ` Alan Cox
2003-05-09 17:07   ` Valdis.Kletnieks
2003-05-10 15:34     ` Alan Cox
2003-05-08 19:43 Chuck Ebbert
2003-05-08 19:43 Chuck Ebbert
2003-05-08 19:58 ` Christoph Hellwig
2003-05-09 13:53 ` Jesse Pollard
2003-05-09 14:37   ` Ragnar =?unknown-8bit?Q?Kj=F8rstad?=
2003-05-12 14:19     ` Jesse Pollard
2003-05-12 15:56       ` Christoph Hellwig
2003-05-08 19:43 Chuck Ebbert
2003-05-08 19:48 ` Christoph Hellwig
2003-05-08 21:44 ` Alan Cox
2003-05-08 14:08 Chuck Ebbert
2003-05-08 14:36 ` Christoph Hellwig
2003-05-08 14:42 ` Alan Cox
2003-05-08 14:56 ` Jesse Pollard
2003-05-08 15:22   ` Alan Cox
2003-05-08 17:02     ` William Stearns
2003-05-08 18:28     ` Jesse Pollard
2003-05-10 14:38     ` Ahmed Masud
2003-05-10 16:50       ` Arjan van de Ven
2003-05-10 17:51         ` Ahmed Masud
2003-05-10 17:56           ` Arjan van de Ven
2003-05-10 18:03             ` Ahmed Masud
2003-05-10 18:09             ` Ahmed Masud
2003-05-10 18:43           ` Werner Almesberger
2003-05-10 18:26         ` Werner Almesberger
2003-05-11 11:01         ` Terje Malmedal
2003-05-11 11:57           ` Ahmed Masud
2003-05-07 19:04 Chuck Ebbert
2003-05-08  9:58 ` Terje Eggestad
2003-05-08  9:59   ` Arjan van de Ven
2003-05-08 10:20     ` viro
2003-05-08 12:54     ` Terje Eggestad
2003-05-08 12:58       ` Christoph Hellwig
2003-05-08 19:10         ` Shachar Shemesh
2003-05-08 19:15           ` Christoph Hellwig
2003-05-08 21:48             ` J.A. Magallon
2003-05-09  7:43               ` Muli Ben-Yehuda
2003-05-09  7:42             ` Muli Ben-Yehuda
2003-05-09  8:08               ` Greg KH
2003-05-09 19:07                 ` Muli Ben-Yehuda
2003-05-07 15:34 petter wahlman
2003-05-07 15:48 ` Arjan van de Ven
2003-05-07 16:00 ` Richard B. Johnson
2003-05-07 16:08   ` petter wahlman
2003-05-07 16:45     ` Richard B. Johnson
2003-05-07 16:59     ` Richard B. Johnson
2003-05-07 18:07       ` petter wahlman
2003-05-07 18:33         ` Richard B. Johnson
2003-05-08  8:58           ` petter wahlman
2003-05-08 15:11             ` Richard B. Johnson
2003-05-07 21:27         ` Jesse Pollard
2003-05-07 17:21     ` Jesse Pollard
2003-05-07 16:18 ` Steffen Persvold
2003-05-08 12:23   ` Eric W. Biederman
2003-05-06 20:48 Chuck Ebbert
2003-05-06 15:51 Yoav Weiss
2003-05-06  8:45 Yoav Weiss
2003-05-06  9:15 ` David S. Miller
2003-05-06 19:45   ` David Schwartz
2003-05-06 10:06 ` Dmitry A. Fedorov
2003-05-06 17:01 ` Jerry Cooperstein
2003-05-06 17:45   ` Yoav Weiss
2003-05-05 21:29 Chuck Ebbert
2003-05-05 22:49 ` Terje Eggestad
2003-05-06  2:23   ` Dmitry A. Fedorov
2003-05-06  7:27     ` Terje Eggestad
2003-05-06  8:21       ` Dmitry A. Fedorov
     [not found] <mailman.1052142720.4060.linux-kernel2news@redhat.com>
2003-05-05 20:50 ` Pete Zaitcev
2003-05-06  2:17   ` Dmitry A. Fedorov
2003-05-05 13:30 Dmitry A. Fedorov
2003-05-05 13:42 ` Christoph Hellwig
2003-05-05 14:46   ` Dmitry A. Fedorov
2003-05-05 13:45 ` viro
2003-05-05 14:29   ` Dmitry A. Fedorov
2003-05-05  8:19 Terje Eggestad
2003-05-05  8:23 ` Christoph Hellwig
2003-05-05  9:33   ` Terje Eggestad
2003-05-05  9:38     ` Arjan van de Ven
2003-05-05 10:12       ` Terje Eggestad
2003-05-05 10:25     ` Christoph Hellwig
2003-05-05 11:23       ` Terje Eggestad
2003-05-05 11:27         ` Arjan van de Ven
2003-05-05 11:31         ` Terje Eggestad
2003-05-05 11:33           ` Arjan van de Ven
2003-05-05 15:53             ` Tigran Aivazian
2003-05-05 14:57               ` Christoph Hellwig
2003-05-05 14:59               ` Arjan van de Ven
2003-05-05 12:52         ` Christoph Hellwig
2003-05-05 13:41           ` Terje Eggestad
2003-05-05 13:43             ` Christoph Hellwig
2003-05-05 13:50               ` Terje Eggestad
2003-05-05 13:54                 ` Arjan van de Ven
2003-05-05 13:55                 ` Christoph Hellwig
2003-05-05 14:28                   ` Carl-Daniel Hailfinger
2003-05-05 14:34                     ` Christoph Hellwig
2003-05-05 15:25                       ` Carl-Daniel Hailfinger
2003-05-06  7:30       ` Eric W. Biederman
2003-05-06  8:14         ` Terje Eggestad
2003-05-06  9:21           ` Eric W. Biederman
2003-05-06 11:21             ` Terje Eggestad
2003-05-06 11:37               ` Eric W. Biederman
2003-05-06 12:08                 ` Terje Eggestad
2003-05-05 11:16     ` Alan Cox
2003-05-05 13:23       ` Terje Eggestad
2003-05-08 12:25       ` Terje Malmedal
2003-05-08 12:29         ` Christoph Hellwig
2003-05-08 13:18           ` Terje Malmedal
2003-05-08 14:25             ` Christoph Hellwig
2003-05-08 15:29               ` Terje Malmedal
2003-05-08 18:13                 ` Jesse Pollard
2003-05-08 19:17                   ` Christoph Hellwig
2003-05-09  9:18                   ` Terje Malmedal
2003-05-08 14:58         ` Alan Cox
2003-05-09  8:56           ` Terje Malmedal
2003-05-07  2:14     ` Ben Lau
2003-05-05  8:27 ` Arjan van de Ven
2003-05-05  9:01 ` Dmitry A. Fedorov
2003-05-05  9:19   ` Christoph Hellwig
2003-05-05  9:32   ` Arjan van de Ven

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).