Re: As 2.0 looms

Marek Michalkiewicz (marekm@i17linuxb.ists.pwr.wroc.pl)
Wed, 24 Apr 1996 17:40:41 +0200 (MET DST)


Alan Cox:
> A lot of people are having trouble with path mtu discovery if enabled.
> Almost all of these are people using NCSA telnet - its buggy, tough, go fix.

There is a fixed version somewhere on ftp.upe.ac.za (sorry, I don't
remember the exact pathname, and this site is very slow from here).
It may or may not be faster for you to get it from
ftp://ftp.ists.pwr.wroc.pl/pub/msdos/telnet/ncsa_upe/tel23074.zip
(source is in v230704s.zip). I have tested it with 1.3.79 (with
path mtu discovery enabled - ncsa 2.3.08 didn't work) and it seems
to work. I don't know if anyone is working on this code - this
version is over a year old. Too bad - it's faster and often more
stable than these windoze telnets, and runs on almost anything...

Now back to things to fix before 2.0:

- /proc is still insecure :-(. You can open /proc/<pid>/mem and
hold the file descriptor, then have the target process exec some
setuid/setgid/unreadable program and read its memory at will.
Not good for things like ssh - the secret host key is there...

- somewhat related: it shouldn't be possible to ptrace unreadable
programs (just like set[ug]id), they may be unreadable for a reason
like encryption key compiled in, etc. Also, ld.so needs some way
to know the program is unreadable so it won't accept LD_xxx (this
may need kernel support, syscall to read the dumpable flag maybe?)

- do we still have the verify_area/memcpy race? (I guess yes, but
I hope I am wrong... what if the area is unmapped while the process
sleeps between verify_area and memcpy?)

- bad_user_access_length should be available to modules for old gcc
users, in ksyms.c or perhaps as inline function conditional on the
version of gcc? (otherwise at least ncpfs won't load)

- not a real bug but it would be nice to have the SAK patch in the
standard kernel. Any reason why it isn't yet?

Marek