[555] in linux-security and linux-alert archive
Re: /proc insecurity
daemon@ATHENA.MIT.EDU (Ian Jackson)
Mon Jan 8 12:44:45 1996
Date: Sat, 6 Jan 96 18:59 GMT
From: Ian Jackson <ian@chiark.chu.cam.ac.uk>
To: Linux Security list <linux-security@tarsier.cv.nrao.edu>
(Oops, resending this because I got the address wrong.)
[Mod: Old ("wrong") headers removed. --Jeff.]
Aaron Ucko writes ("Re: /proc insecurity"):
> [Ian Jackson wrote:]
> > Marek Michalkiewicz writes ("/proc insecurity"):
> > > As we probably already know, the /proc filesystem still has security
> > > problems. [...]
> > >
> ...
> > > The only simple fix I can see for 1.2.xx is to make /proc/<pid>/*
> > > owned by root for all processes.
> >
> > I have done this, and it works. My patch is below. You have to mount
> > the procfs with -o paranoid for it to take effect.
> >
> > I've also prevented /proc/<pid>/fd from working, as you can otherwise
> > steal filedescriptors in much the same way as you describe.
> ...
>
> Aren't less draconian measures possible? "There's gotta be a better way."
These measures may be draconian, but they are demonstrably secure.
There is a strong tendency here to say "ah, but in situation XYZ this
is OK", and to construct very complicated mechanisms. This is simply
not good enough, because your security then depends on you having
designed and implemented all of the complicated security mechanisms
correctly and not overlooking anything.
I'm worried that in 1.3.x it won't be easy to show to someone that
/proc isn't harmful to their security, in the way that it is easy for
me to show someone that my patched 1.2 isn't a security hole.
Why should I believe it is secure if you can't easily show it to me ?
> Was the problem that you couldn't compile it or that it segfaulted when
> you tried to run it? If it was the latter, the problem is due to a
> symbol clash I noticed and reported to its maintainer (Rick Sladkin),
> but who hasn't released a fixed version yet: Both strace and libc
> have functions called syscall; the library attempts to call strace's
> version and crashes. (The solution, of course, involves renaming
> syscall in strace.)
I couldn't compile it. The number of symbol clashes &c with system
header files was tremendous. Perhaps I was doing something wrong, but
this is a Debian source package so you're *supposed* just to be able
to type `make -f debian.rules build'.
Ian.
