Re: Disturbing news..

[Dr. Kelsey Hudson]

On Wed, 28 Mar 2001, Jesse Pollard wrote:
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.

Oh, honestly! Think about what you are saying here:

What if you are developing something in an interpereted language such as
perl or a shell script, where you *directly modify the executable file*?

No, this won't work...Not wwithout being annoying as hell.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jesse Pollard]

Walter Hofmann <[EMAIL PROTECTED]>:
> On Wed, 28 Mar 2001, Jesse Pollard wrote:
[snip]
> > Now, if ELF were to be modified, I'd just add a segment checksum
> > for each segment, then put the checksum in the ELF header as well as
> > in the/a segment header just to make things harder. At exec time a checksum
> > verify could (expensive) be done on each segment. A reduced level could be
> > done only on the data segment or text segment. This would at least force
> > the virus to completly read the file to regenerate the checksum.
> 
> So? The virus will just redo the checksum. Sooner or later their will be a
> routine to do this in libbfd and this all reduces to a single additional
> line of code. 

true.

> > That change would even allow for signature checks of the checksum if the
> > signature was stored somewhere else (system binaries/setuid binaries...).
> > But only in a high risk environment. This could even be used for a scanner
> > to detect ANY change to binaries (and fast too - signature check of checksums
> > wouldn't require reading the entire file).
> 
> One sane way to do this is to store the sig on a ro medium and make the
> kernel check the sig of every binary before it is run.

Only for trusted binaries. (extreme paranoia now).
 
> HOWEVER, this means no compilers will work, and you have to delete all
> script languages like perl or python (or make all of them check the
> signature).

Compilers should work normally, the link phase is what would generate
the checksums, though if each object file contained a checksum for the
segment then the interpreters/dynamic loaders would have the choice.

The only applications I see as really needing to check such signatures
are those using PAM. These should do it anyway. The dynamic linking programs
should do so only if they are configured to do so.

> Useless again, IMO.
> 
> > In any case, the problem is limited to one user, even if nothing is done.
> 
> Your best bet is to educate your users.

User eduation is a reasonable substitute as long as they can be directed
to follow the rules.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Walter Hofmann]

On Wed, 28 Mar 2001, Jesse Pollard wrote:

> By itself it doesn't - but if you also don't have user/group/world rw and
> don't own the file, you can't do anything to it.

This is all completely useless. Why not remove world rw permissions in the
first place. If the admin isn't even able to write a cron job that does
this, all help is lost.

> It's only there to reduce accidents. If you want to go full out,
> remove the symbols from the file.

Just as useless.

> Now, if ELF were to be modified, I'd just add a segment checksum
> for each segment, then put the checksum in the ELF header as well as
> in the/a segment header just to make things harder. At exec time a checksum
> verify could (expensive) be done on each segment. A reduced level could be
> done only on the data segment or text segment. This would at least force
> the virus to completly read the file to regenerate the checksum.

So? The virus will just redo the checksum. Sooner or later their will be a
routine to do this in libbfd and this all reduces to a single additional
line of code. 

> That change would even allow for signature checks of the checksum if the
> signature was stored somewhere else (system binaries/setuid binaries...).
> But only in a high risk environment. This could even be used for a scanner
> to detect ANY change to binaries (and fast too - signature check of checksums
> wouldn't require reading the entire file).

One sane way to do this is to store the sig on a ro medium and make the
kernel check the sig of every binary before it is run.

HOWEVER, this means no compilers will work, and you have to delete all
script languages like perl or python (or make all of them check the
signature).

Useless again, IMO.

> In any case, the problem is limited to one user, even if nothing is done.

Your best bet is to educate your users.

Walter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Helge Hafting]

Ben Ford wrote:
> 

> There are two problems I see here.  First, there are several known ways
> to elevate privileges.  
Fixable, except from guessing the root password which is hard.

> If a virus can elevate privileges, then it owns
> you.  Second, this is a multi-OS virus.  If you dual-boot into Windows,
> any ELF files accessible can be infected.  With this one, that isn't a
> prob, but when somebody codes in an ext2 driver to their virus, then
> we've got issues.

And the only cure then is not make your linux fs accessible from
windows.  I.e. not on a disk for which windows have a driver
installed.  Preferably not the same computer.

Or simply "don't run untrusted executables under windows".  Do
so in linux only, where protection applies.  Do anybody ever
_need_ to run a program they got in the mail?

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Gerhard Mack]

On Wed, 28 Mar 2001 [EMAIL PROTECTED] wrote:

> Jesse Pollard writes:
> > Absolutely true. The only help the checksumming etc stuff is good for is
> > detecting the fact afterward by external comparison.
> 
> Don't we already have that to some extent?  rpm -ya or rpm -y 
> on a RedHat system?  I'm sure that there is a Debian equivalent.

http://www.tripwire.com does exactly this afik. 

Gerhard

--
Gerhard Mack

[EMAIL PROTECTED]

<>< As a computer I find your faith in technology amusing.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Ben Ford]

Simon Williams wrote:

> In message <[EMAIL PROTECTED]>, Olivier Galibert
> <[EMAIL PROTECTED]> writes
> 
>> On Wed, Mar 28, 2001 at 03:04:46PM +0100, Simon Williams wrote:
>> 
>>> I think their point was that a program could only change permissions
>>> of a file that was owned by the same owner.  If a file is owned by a
>>> different user & has no write permissions for any user, the program
>>> can't modify the file or it's permissions.
>> 
>> You mean, you usually have write permissions for other than the owner
>> on executable files?
>> 
>> Let me reformulate that.  You usually have write permissions for other
>> than the owner, and not only on some special, untrusted log files (I'm
>> talking files, here, not device nodes)?  What's your umask, 0?
>> 
> 
> Firstly, I'm relatively new to Linux (only about 3 yrs experience) &
> don't claim to be an expert.  Secondly, I don't think I stated my point
> very clearly.
> 
> No, I don't have write permissions set on an executable for any user
> other than the owner.
> 
> What I meant was that if a file is owned by root with permissions of,
> say, 555 (r-xr-xr-x), not setuid or setgid, then another executable
> run as a non-root user cannot modify it or change the permissions to
> 7 (rwx).

There are two problems I see here.  First, there are several known ways 
to elevate privileges.  If a virus can elevate privileges, then it owns 
you.  Second, this is a multi-OS virus.  If you dual-boot into Windows,  
any ELF files accessible can be infected.  With this one, that isn't a 
prob, but when somebody codes in an ext2 driver to their virus, then 
we've got issues.

-b

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Olivier Galibert]

On Wed, Mar 28, 2001 at 04:49:26PM +0100, Simon Williams wrote:
> What I meant was that if a file is owned by root with permissions of,
> say, 555 (r-xr-xr-x), not setuid or setgid, then another executable
> run as a non-root user cannot modify it or change the permissions to
> 7 (rwx).

It's already the case that a file owned by user A cannot have its
rights changed by user B.  Also, if the write permission is not set,
you can't modify the file.  That's the basic unix security model.  Of
course, if you're root all best are off, root is god.  For those who
con't like that, there are things like capabilities and MAC.  But they
are _really_ hard to setup correctly.

What they are talking about is to have the x bit cancel the w bit,
i.e. make the rwx files unwritable.  Fixing the symptoms, you know...


> My policy is to give necessary permissions & no more.

This is not a bad policy.  Removing read permissions can make fixing
problems a pain, though (what, no gdb/strace of system executables?).


> I would set the
> aforementioned permissions on the main system binaries which would allow
> other users to get on with what they need to do without being able to
> affect the workspaces of other users, only their own.

Well, the main system binaries are already that way (r-xr-xr-x or
rwxr-xr-x, which when root-owned are equivalent).  I don't see your
point.

  OG.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Horst von Brand]

Shawn Starr <[EMAIL PROTECTED]> said:
> Well, why can't the ELF loader module/kernel detect or have some sort of
> restriction on modifying other/ELF binaries including itself from changing
> the Entry point?

Because there are quite valid reasons for "normal" programs (e.g., ld(1)
and other binary-futzing tools) to do so. No, I don't want a paranoic
system where I (regular user) can't do this to my own files using a random
binary editor. An executable is just a normal file in Unix, can't get
around this without seriously breaking lots of stuff.
-- 
Dr. Horst H. von Brand   mailto:[EMAIL PROTECTED]
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria  +56 32 654239
Casilla 110-V, Valparaiso, ChileFax:  +56 32 797513
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Romano Giannetti]

On Wed, Mar 28, 2001 at 09:57:47AM -0500, Alexander Viro wrote:
> 
> On Wed, 28 Mar 2001, Romano Giannetti wrote:
> 
> > Now the binary can do much less harm than before, or am I missing something?
> > It have no access to real user data, but can use the system library and
> > services without changing anything in the system. 
> 
> You mean, like mailbombing the living hell out of somebody? Or playing
> interesting games with sending signals all over the place...

Yes, I was sure there were doors left, but --- it has no access to the
bookmark list of user, and can kill just user processes... that was what I
meant with "less harm" (never say never, I know...). 

   Romano 

-- 
Romano Giannetti -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 411 132
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jonathan Lundell]

 john slee <[EMAIL PROTECTED]> says:

>On Wed, Mar 28, 2001 at 03:10:08PM +0100, Sean Hunter wrote:
>> On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
>> > Sure - very simple. If the execute bit is set on a file, don't allow
>> > ANY write to the file. This does modify the permission bits slightly
>> > but I don't think it is an unreasonable thing to have.
>> >
>>
>> Are we not then in the somewhat zen-like state of having an "rm" which can't
>> "rm" itself without needing to be made non-executable so that it can't execute?
>
>aeee, my head hurts now, thanks :(

It shouldn't. rm is not prevented from removing an unwriteable file (though it 
complains by default). Directory permissions control operations on links.

-- 
/Jonathan Lundell.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[rmk]

Jesse Pollard writes:
> Absolutely true. The only help the checksumming etc stuff is good for is
> detecting the fact afterward by external comparison.

Don't we already have that to some extent?  rpm -ya or rpm -y 
on a RedHat system?  I'm sure that there is a Debian equivalent.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Simon Williams]

In message <[EMAIL PROTECTED]>, Olivier Galibert
<[EMAIL PROTECTED]> writes
>On Wed, Mar 28, 2001 at 03:04:46PM +0100, Simon Williams wrote:
>> I think their point was that a program could only change permissions
>> of a file that was owned by the same owner.  If a file is owned by a
>> different user & has no write permissions for any user, the program
>> can't modify the file or it's permissions.
>
>You mean, you usually have write permissions for other than the owner
>on executable files?
>
>Let me reformulate that.  You usually have write permissions for other
>than the owner, and not only on some special, untrusted log files (I'm
>talking files, here, not device nodes)?  What's your umask, 0?
>

Firstly, I'm relatively new to Linux (only about 3 yrs experience) &
don't claim to be an expert.  Secondly, I don't think I stated my point
very clearly.

No, I don't have write permissions set on an executable for any user
other than the owner.

What I meant was that if a file is owned by root with permissions of,
say, 555 (r-xr-xr-x), not setuid or setgid, then another executable
run as a non-root user cannot modify it or change the permissions to
7 (rwx).

>
>> Sounds like a good plan to me.
>
>PEBCAK.  Unix security is not designed with dumb "administrators" in
>mind, nor should be.  User friendly is good.  Luser friendly isn't,
>it's either dumbing down or unnecessarily restrictive.
>

I completely agree (even with the PEBCAK part :)).  UNIX security on
corporate networks or public-facing systems should be left to experts.
I, on the other hand, am a home-user trying to learn how Linux works &
how to secure it, I don't pretend to be an expert.

My policy is to give necessary permissions & no more.  I would set the
aforementioned permissions on the main system binaries which would allow
other users to get on with what they need to do without being able to
affect the workspaces of other users, only their own.

I'm open to contructive criticism on this.


-- 
Simon Williams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jesse Pollard]

Russell King <[EMAIL PROTECTED]>
> 
> On Wed, Mar 28, 2001 at 08:40:42AM -0600, Jesse Pollard wrote:
> > Now, if ELF were to be modified, I'd just add a segment checksum
> > for each segment, then put the checksum in the ELF header as well as
> > in the/a segment header just to make things harder. At exec time a checksum
> > verify could (expensive) be done on each segment. A reduced level could be
> > done only on the data segment or text segment. This would at least force
> > the virus to completly read the file to regenerate the checksum.
> 
> Checksums don't help that much - virus writers would treat it as "part
> of the set of alterations that need to be made" and then the checksum
> becomes zero protection.
> 
 [ snip of good stuff ]
> Therefore, if you follow good easy system administration techniques, then
> you end up minimising the risk of getting:
> 
> 1. viruses
> 2. trojans
> 3. malicious users
> 
> cracking your system.  If you don't follow these techniques, then you're
> asking for lots of trouble, and no amount of checksumming/signing/etc
> will ever save you.

Absolutely true. The only help the checksumming etc stuff is good for is
detecting the fact afterward by external comparison.

I like MLS for the ability to catch ATTEMPTS to make unauthorized
modification.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jesse Pollard]

Russell King <[EMAIL PROTECTED]>:
> On Wed, Mar 28, 2001 at 08:15:57AM -0600, Jesse Pollard wrote:
> > objcopy - copies object files. Object files are not marked executable...
> 
> objcopy copies executable files as well - check the kernel makefiles
> for examples.

At the time it's copying, the input doesn't need to be executable. That
appears to be a byproduct of a library link.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jesse Pollard]

Sean Hunter <[EMAIL PROTECTED]>:
> On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> > Sure - very simple. If the execute bit is set on a file, don't allow
> > ANY write to the file. This does modify the permission bits slightly
> > but I don't think it is an unreasonable thing to have.
> > 
> 
> Are we not then in the somewhat zen-like state of having an "rm" which can't
> "rm" itself without needing to be made non-executable so that it can't execute?

We've been in that state for a long time... (carefull updating that libc.so
file... can't overwrite/delete without having some REAL problems show up.)

It just calls for some carefull activity. If rm is being replaced, first
rename it; then put new one in place; chmod old; delete old. It is directly
comparable to the libc.so update procedure.

I should have left off the "very simple" remark.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[john slee]

[cc list trimmed]

On Wed, Mar 28, 2001 at 03:10:08PM +0100, Sean Hunter wrote:
> On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> > Sure - very simple. If the execute bit is set on a file, don't allow
> > ANY write to the file. This does modify the permission bits slightly
> > but I don't think it is an unreasonable thing to have.
> >
> 
> Are we not then in the somewhat zen-like state of having an "rm" which can't
> "rm" itself without needing to be made non-executable so that it can't execute?

aeee, my head hurts now, thanks :(

j.

-- 
"Bobby, jiggle Grandpa's rat so it looks alive, please" -- gary larson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Russell King]

On Wed, Mar 28, 2001 at 08:40:42AM -0600, Jesse Pollard wrote:
> Now, if ELF were to be modified, I'd just add a segment checksum
> for each segment, then put the checksum in the ELF header as well as
> in the/a segment header just to make things harder. At exec time a checksum
> verify could (expensive) be done on each segment. A reduced level could be
> done only on the data segment or text segment. This would at least force
> the virus to completly read the file to regenerate the checksum.

Checksums don't help that much - virus writers would treat it as "part
of the set of alterations that need to be made" and then the checksum
becomes zero protection.

Your system binaries are safe from the virus (from my understanding of the
poor writeup) if you are sensible about your system - ie, don't run stuff
as the root user, don't login as root, ensure that your binaries are owned
by root etc.

If users have their own binaries, then they should take adequate care
over them (find ~ -type f -perm +111 | xargs chmod a-w) to ensure that
they are not writable (this applies to your argument as well).

Once you're in this situation:

1. Users can't write to their executables without first chmod'ing them.
   (won't take long for a virus writer to get the idea that they should
   chmod +w them first).

2. If a user binary becomes infected, only people able to run that binary
   also become infected.  Certainly root should under no circumstances
   run any program which a user has compiled - the user may have some
   nice code in there which creates another root user in /etc/passwd
   with no password entry.

3. Since you're only running system programs as root (and by that I mean
   stuff for administration, not stuff like mail clients, news readers
   etc), your system binaries should not become infected.

Therefore, if you follow good easy system administration techniques, then
you end up minimising the risk of getting:

1. viruses
2. trojans
3. malicious users

cracking your system.  If you don't follow these techniques, then you're
asking for lots of trouble, and no amount of checksumming/signing/etc
will ever save you.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Olivier Galibert]

On Wed, Mar 28, 2001 at 03:04:46PM +0100, Simon Williams wrote:
> I think their point was that a program could only change permissions
> of a file that was owned by the same owner.  If a file is owned by a
> different user & has no write permissions for any user, the program
> can't modify the file or it's permissions.

You mean, you usually have write permissions for other than the owner
on executable files?

Let me reformulate that.  You usually have write permissions for other
than the owner, and not only on some special, untrusted log files (I'm
talking files, here, not device nodes)?  What's your umask, 0?


> Sounds like a good plan to me.

PEBCAK.  Unix security is not designed with dumb "administrators" in
mind, nor should be.  User friendly is good.  Luser friendly isn't,
it's either dumbing down or unnecessarily restrictive.

  OG, who waits for the first insmod-ing "virus"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Bill Rugolsky Jr.]

On Wed, Mar 28, 2001 at 04:32:44PM +0200, Romano Giannetti wrote:
> But with the new VFS semantics, wouldn't be possible for a MUA to make a
> thing like the following: 
> 
> spawn a process with a private namespace. Here a minimun subset of the
> "real" tree (maybe all / except /dev) is mounted readonly. The private /tmp
> and /home/user are substituted by read-write directory that are in the
> "real" tree /home/user/mua/fakehome and /home/user/mua/faketmp. In this
> private namespace, run the "untrusted" binary. 

Possible and desirable.  You have to turn off access to all the other
dangerous namespaces though, like socket() and shmat(), and make sure
that nosuid and devices are handled properly. Done right, the only thing
that untrusted code can do is consume a little memory, CPU, and disk,
but that's why there are limits and a scheduler. :-)

One might even want to add back limited access to those other namespaces
by implementing a filesystem interface, ala Plan-9/Inferno.

Regards,

   Bill Rugolsky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Russell King]

On Wed, Mar 28, 2001 at 08:15:57AM -0600, Jesse Pollard wrote:
> objcopy - copies object files. Object files are not marked executable...

objcopy copies executable files as well - check the kernel makefiles
for examples.

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Alexander Viro]

On Wed, 28 Mar 2001, Romano Giannetti wrote:

> Now the binary can do much less harm than before, or am I missing something?
> It have no access to real user data, but can use the system library and
> services without changing anything in the system. 

You mean, like mailbombing the living hell out of somebody? Or playing
interesting games with sending signals all over the place...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jesse Pollard]

-  Received message begins Here  -

> 
> On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> > Sure - very simple. If the execute bit is set on a file, don't allow
> > ANY write to the file. This does modify the permission bits slightly
> > but I don't think it is an unreasonable thing to have.
> 
> Even easier method - remove the write permission bits from all executable
> files, and don't do the unsafe thing of running email/web browsers/other
> user-type stuff as user root.
> 
> If it still worries you that root can write to files without the 'w' bit
> set, modify the capabilities of the system to prevent it (there is a bit
> that can be set which will remove this ability for all new processes).

How about just adding MLS ... :-)

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jesse Pollard]

> 
> 
> 
> On Wed, 28 Mar 2001, Jesse Pollard wrote:
> 
> > >Any idea?
> > 
> > Sure - very simple. If the execute bit is set on a file, don't allow
> > ANY write to the file. This does modify the permission bits slightly
> > but I don't think it is an unreasonable thing to have.
> 
> And how exactly does this help?
> 
> fchmod (fd, 0666);
> fwrite (fd, ...);
> fchmod (fd, 0777);

By itself it doesn't - but if you also don't have user/group/world rw and
don't own the file, you can't do anything to it.

It's only there to reduce accidents. If you want to go full out,
remove the symbols from the file.

Now, if ELF were to be modified, I'd just add a segment checksum
for each segment, then put the checksum in the ELF header as well as
in the/a segment header just to make things harder. At exec time a checksum
verify could (expensive) be done on each segment. A reduced level could be
done only on the data segment or text segment. This would at least force
the virus to completly read the file to regenerate the checksum.

That change would even allow for signature checks of the checksum if the
signature was stored somewhere else (system binaries/setuid binaries...).
But only in a high risk environment. This could even be used for a scanner
to detect ANY change to binaries (and fast too - signature check of checksums
wouldn't require reading the entire file).

In any case, the problem is limited to one user, even if nothing is done.

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Romano Giannetti]

Notice: this is my first post to l-k since some bug report as old as 0.99...
so please be kind, don't beat me to hard.

On Wed, Mar 28, 2001 at 08:25:46AM -0500, Alexander Viro wrote:
 
>  If you run untrusted binaries - you are screwed.  If you run
> them as root - all users on your system are screwed.  If your MUA
> (or browser, etc.) can run untrusted code - see above. 

Too true. 

But with the new VFS semantics, wouldn't be possible for a MUA to make a
thing like the following: 

spawn a process with a private namespace. Here a minimun subset of the
"real" tree (maybe all / except /dev) is mounted readonly. The private /tmp
and /home/user are substituted by read-write directory that are in the
"real" tree /home/user/mua/fakehome and /home/user/mua/faketmp. In this
private namespace, run the "untrusted" binary. 

Now the binary can do much less harm than before, or am I missing something?
It have no access to real user data, but can use the system library and
services without changing anything in the system. 

Having the read-only flag per vfs-mount is the only kernel-related thing
here, I think; all the rest is simply user-space spice :-). 

Have a nice day,
   Romano 


-- 
Romano Giannetti -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 411 132
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jesse Pollard]

Keith Owens <[EMAIL PROTECTED]>
> 
> On Wed, 28 Mar 2001 06:08:15 -0600, 
> Jesse Pollard <[EMAIL PROTECTED]> wrote:
> >Sure - very simple. If the execute bit is set on a file, don't allow
> >ANY write to the file. This does modify the permission bits slightly
> >but I don't think it is an unreasonable thing to have.
> 
> man strip
> man objcopy
> man ld

Thought of theses already (well, at least ld...)

strip - not used that much (most executables still have their symbol table
but could be handled by removing the execute bit, stripping, then
putting it back. Or just use the ld option -s.
objcopy - copies object files. Object files are not marked executable...
ld  - on other UNIX systems (Cray/IRIX), I think the output file
(-o) specified is first deleted. Whenever I can cause a link
error, the output is not marked executable. If the GNU ld doesn't
delete it first, then it most likely should.

I was expecting shell scripts to be the complaint first... :-)

-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Sean Hunter]

On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.
> 

Are we not then in the somewhat zen-like state of having an "rm" which can't
"rm" itself without needing to be made non-executable so that it can't execute?

Sean
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Simon Williams]

In message , Walter
Hofmann <[EMAIL PROTECTED]> writes
>
>
>On Wed, 28 Mar 2001, Jesse Pollard wrote:
>
>> >Any idea?
>> 
>> Sure - very simple. If the execute bit is set on a file, don't allow
>> ANY write to the file. This does modify the permission bits slightly
>> but I don't think it is an unreasonable thing to have.
>
>And how exactly does this help?
>
>fchmod (fd, 0666);
>fwrite (fd, ...);
>fchmod (fd, 0777);
>

I think their point was that a program could only change permissions
of a file that was owned by the same owner.  If a file is owned by a
different user & has no write permissions for any user, the program
can't modify the file or it's permissions.

Sounds like a good plan to me.


-- 
Simon Williams
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Ben Ford]

Jesse Pollard wrote:

> On Wed, 28 Mar 2001, Shawn Starr wrote:
> 
>> Well, why can't the ELF loader module/kernel detect or have some sort of
>> restriction on modifying other/ELF binaries including itself from changing
>> the Entry point?
>> 
>> There has to be a way stop this. WHY would anyone want to modify the entry
>> point anyway? (there may be some reasons but I really dont know what).
>> Even if it's user level, this cant affect files with root permissions
>> (unless root is running them or suid).
>> 
>> Any idea?
> 
> 
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.
> 
What a pain in the ass when you are writing / updating a shell script . 
. . .

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Alexander Viro]

On Wed, 28 Mar 2001, Shawn Starr wrote:

> 
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> 
> Isn't it time to change the ELF format to stop this crap?

 If you run untrusted binaries - you are screwed.  If you run
them as root - all users on your system are screwed.  If your MUA
(or browser, etc.) can run untrusted code - see above.  If you have
a dual-boot system and one of the OSes is compromised - all of them
are.  Nothing to do about that.  What's new here?  Don't be an idiot 
nd don't use crapware...

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Russell King]

On Wed, Mar 28, 2001 at 06:08:15AM -0600, Jesse Pollard wrote:
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.

Even easier method - remove the write permission bits from all executable
files, and don't do the unsafe thing of running email/web browsers/other
user-type stuff as user root.

If it still worries you that root can write to files without the 'w' bit
set, modify the capabilities of the system to prevent it (there is a bit
that can be set which will remove this ability for all new processes).

--
Russell King ([EMAIL PROTECTED])The developer of ARM Linux
 http://www.arm.linux.org.uk/personal/aboutme.html

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Walter Hofmann]

On Wed, 28 Mar 2001, Jesse Pollard wrote:

> >Any idea?
> 
> Sure - very simple. If the execute bit is set on a file, don't allow
> ANY write to the file. This does modify the permission bits slightly
> but I don't think it is an unreasonable thing to have.

And how exactly does this help?

fchmod (fd, 0666);
fwrite (fd, ...);
fchmod (fd, 0777);

Walter

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Keith Owens]

On Wed, 28 Mar 2001 06:08:15 -0600, 
Jesse Pollard <[EMAIL PROTECTED]> wrote:
>Sure - very simple. If the execute bit is set on a file, don't allow
>ANY write to the file. This does modify the permission bits slightly
>but I don't think it is an unreasonable thing to have.

man strip
man objcopy
man ld

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Jesse Pollard]

On Wed, 28 Mar 2001, Shawn Starr wrote:
>Well, why can't the ELF loader module/kernel detect or have some sort of
>restriction on modifying other/ELF binaries including itself from changing
>the Entry point?
>
>There has to be a way stop this. WHY would anyone want to modify the entry
>point anyway? (there may be some reasons but I really dont know what).
>Even if it's user level, this cant affect files with root permissions
>(unless root is running them or suid).
>
>Any idea?

Sure - very simple. If the execute bit is set on a file, don't allow
ANY write to the file. This does modify the permission bits slightly
but I don't think it is an unreasonable thing to have.

>
>On Wed, 28 Mar 2001, Matti Aarnio wrote:
>
>> On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
>> > Date:  Wed, 28 Mar 2001 01:16:02 -0500 (EST)
>> > From:  Shawn Starr <[EMAIL PROTECTED]>
>> > To:<[EMAIL PROTECTED]>
>> > Subject: Disturbing news..
>> >
>> > http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
>> > Isn't it time to change the ELF format to stop this crap?
>> > Shawn.
>>
>>  Why ?   "Double-click on attachment to run it" is typical
>>  M$ client stupidity -- and the reason why there
>>  are so many things that can mail themselves around.
>>
>>  Changeing ELF-format would be comparable to what M$ did when
>>  they met the first Word macro viruses -- they changed the
>>  script language inside the Word...   What good did that do ?
>>  Did it harm people ?  You bet...
>>
>>
>>  You are downloading binaries off the net, and not compiling
>>  from the sources ?  (Yes, we all do that.  This is why folks
>>  these days carry PGP signatures at the RPM packages.)
>>
>>
>>  So, the program modifies ELF format executables by rewriting
>>  some instructions in the beginning (propably to map-in the virus
>>  code proper with X-bit on), and tags itself (PIC presumably) at
>>  the end of the file.
>>
>>
>>
>>  Another issue is "safe conduct" practice of installing binaries
>>  with minimum privileges (ok, granted that for e.g. RPMs that
>>  usually means root), and *never* running them with undue levels
>>  of privileges -- not even as the owner of said executables.
>>
>>
>>
>>  Ok, granted that we have dangers of getting arbitrary BAD programs
>>  into our systems, how can we combat that ?   Virus-scanners
>>  (as much good as they could do..) don't really work in UNIX
>>  environments where "small things" like intercept of every
>>  exec(), and open() via privileged program (scanner) is not
>>  available feature. (I think doing it by passing a AF_UNIX
>>  message with fd + flags to registered server, expecting answer
>>  for the open() -- this would happen *after* the file open is
>>  done with user privileges, but before the call returns.)
>>  (Trapping open() so that shared-libraries could be scanned.)
>>
>>  There could be, I think, a method for doing such intercepts,
>>  which could be used by security scanners to implement some
>>  sense of security in Linux-like systems.
>>
>>  Is it good enough, e.g. when some file is multiply-mapped to
>>  shared programs, and application rewrites parts of the file ?
>>  Can it detect that kind of multi-mapped writing-sharing ?
>>
>>  Can such system be made fast ?  (Scanner becomes performance
>>  bottle-neck.)
>>
>>
>>  How about PROPER Orange Book B-level security ?
>>  E.g. NSA trusted-linux ?
>>
>>
>> /Matti Aarnio
>>
>>
>
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [EMAIL PROTECTED]
>More majordomo info at  http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at  http://www.tux.org/lkml/
-- 
-
Jesse I Pollard, II
Email: [EMAIL PROTECTED]

Any opinions expressed are solely my own.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Helge Hafting]

Shawn Starr wrote:
> 
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> 
> Isn't it time to change the ELF format to stop this crap?
> 
Nothing to worry about.
A sane distribution have all executables installed read-only
and owned by root or some non-user.  

Email appliacations and file browsers etc. are run as normal
users.  So, even if the user stupidly run this mysterious
program he got in the mail - what happens?

It search for all ELF executables in the system and find
it can open none!  They are not writeable, and the
user don't own them so the bad program cannot change
permissions in order to modify the executables either.

About the only "danger" here is messing with a developer's
program being developed, but he can recompile it
and loose the virus that way.  And a developer wouldn't
trust a program he got in the mail in the first place.
Those dumb enough don't have any writeable executables.

Helge Hafting
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Shawn Starr]

Well, why can't the ELF loader module/kernel detect or have some sort of
restriction on modifying other/ELF binaries including itself from changing
the Entry point?

There has to be a way stop this. WHY would anyone want to modify the entry
point anyway? (there may be some reasons but I really dont know what).
Even if it's user level, this cant affect files with root permissions
(unless root is running them or suid).

Any idea?

On Wed, 28 Mar 2001, Matti Aarnio wrote:

> On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
> > Date:   Wed, 28 Mar 2001 01:16:02 -0500 (EST)
> > From:   Shawn Starr <[EMAIL PROTECTED]>
> > To: <[EMAIL PROTECTED]>
> > Subject: Disturbing news..
> >
> > http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> > Isn't it time to change the ELF format to stop this crap?
> > Shawn.
>
>   Why ?   "Double-click on attachment to run it" is typical
>   M$ client stupidity -- and the reason why there
>   are so many things that can mail themselves around.
>
>   Changeing ELF-format would be comparable to what M$ did when
>   they met the first Word macro viruses -- they changed the
>   script language inside the Word...   What good did that do ?
>   Did it harm people ?  You bet...
>
>
>   You are downloading binaries off the net, and not compiling
>   from the sources ?  (Yes, we all do that.  This is why folks
>   these days carry PGP signatures at the RPM packages.)
>
>
>   So, the program modifies ELF format executables by rewriting
>   some instructions in the beginning (propably to map-in the virus
>   code proper with X-bit on), and tags itself (PIC presumably) at
>   the end of the file.
>
>
>
>   Another issue is "safe conduct" practice of installing binaries
>   with minimum privileges (ok, granted that for e.g. RPMs that
>   usually means root), and *never* running them with undue levels
>   of privileges -- not even as the owner of said executables.
>
>
>
>   Ok, granted that we have dangers of getting arbitrary BAD programs
>   into our systems, how can we combat that ?   Virus-scanners
>   (as much good as they could do..) don't really work in UNIX
>   environments where "small things" like intercept of every
>   exec(), and open() via privileged program (scanner) is not
>   available feature. (I think doing it by passing a AF_UNIX
>   message with fd + flags to registered server, expecting answer
>   for the open() -- this would happen *after* the file open is
>   done with user privileges, but before the call returns.)
>   (Trapping open() so that shared-libraries could be scanned.)
>
>   There could be, I think, a method for doing such intercepts,
>   which could be used by security scanners to implement some
>   sense of security in Linux-like systems.
>
>   Is it good enough, e.g. when some file is multiply-mapped to
>   shared programs, and application rewrites parts of the file ?
>   Can it detect that kind of multi-mapped writing-sharing ?
>
>   Can such system be made fast ?  (Scanner becomes performance
>   bottle-neck.)
>
>
>   How about PROPER Orange Book B-level security ?
>   E.g. NSA trusted-linux ?
>
>
> /Matti Aarnio
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news..

[Matti Aarnio]

On Wed, Mar 28, 2001 at 01:16:02AM -0500, Shawn Starr wrote:
> Date: Wed, 28 Mar 2001 01:16:02 -0500 (EST)
> From: Shawn Starr <[EMAIL PROTECTED]>
> To:   <[EMAIL PROTECTED]>
> Subject: Disturbing news..
> 
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
> Isn't it time to change the ELF format to stop this crap?
> Shawn.

Why ?   "Double-click on attachment to run it" is typical
M$ client stupidity -- and the reason why there
are so many things that can mail themselves around.

Changeing ELF-format would be comparable to what M$ did when
they met the first Word macro viruses -- they changed the
script language inside the Word...   What good did that do ?
Did it harm people ?  You bet...


You are downloading binaries off the net, and not compiling
from the sources ?  (Yes, we all do that.  This is why folks
these days carry PGP signatures at the RPM packages.)


So, the program modifies ELF format executables by rewriting
some instructions in the beginning (propably to map-in the virus
code proper with X-bit on), and tags itself (PIC presumably) at
the end of the file.



Another issue is "safe conduct" practice of installing binaries
with minimum privileges (ok, granted that for e.g. RPMs that
usually means root), and *never* running them with undue levels
of privileges -- not even as the owner of said executables.



Ok, granted that we have dangers of getting arbitrary BAD programs
into our systems, how can we combat that ?   Virus-scanners
(as much good as they could do..) don't really work in UNIX
environments where "small things" like intercept of every
exec(), and open() via privileged program (scanner) is not
available feature. (I think doing it by passing a AF_UNIX
message with fd + flags to registered server, expecting answer
for the open() -- this would happen *after* the file open is
done with user privileges, but before the call returns.)
(Trapping open() so that shared-libraries could be scanned.)

There could be, I think, a method for doing such intercepts,
which could be used by security scanners to implement some
sense of security in Linux-like systems.

Is it good enough, e.g. when some file is multiply-mapped to
shared programs, and application rewrites parts of the file ?
Can it detect that kind of multi-mapped writing-sharing ?

Can such system be made fast ?  (Scanner becomes performance
bottle-neck.)


How about PROPER Orange Book B-level security ?
E.g. NSA trusted-linux ?


/Matti Aarnio
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Disturbing news.. Idea

[Shawn Starr]

Why not make a new file permission?

to deny a ELF binary the ability to modify the ELF entry point?

like +p if the file had +p (by default) the kernel would deny the ELF
binary the ability to modify files.

Shawn.

On Wed, 28 Mar 2001, Shawn Starr wrote:

>
> http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh
>
> Isn't it time to change the ELF format to stop this crap?
>
> Shawn.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>
>

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Disturbing news..

[Shawn Starr]

http://news.cnet.com/news/0-1003-200-5329436.html?tag=lh

Isn't it time to change the ELF format to stop this crap?

Shawn.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/