Subject: Re: locking dynamic libraries against writes (was: a.out dynamic libraries)
To: None <tech-toolchain@NetBSD.ORG>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
Date: 05/25/1998 09:43:51
>> I could go for a special flag to mmap(2)...
>> I'd much rather have a flag bit to mmap(2) [...]
> I thought of doing this through mmap(2) already, and I think I'm
> already ahead of you here, although....
>> The major disadvantage, I think, is that it means that any file you
>> can read you can ETXTBUSY out by mmapping it with this bit set.
Come to think of it, this, or something like it, applies to *any*
solution to the problem under discussion. If ld.so can block writes to
arbitrary files, then an attacker can use the same mechanism to block
writes to arbitrary files. (See my next paragraph.)
> Then again I suppose if this were an optional flag to mmap(2) one
> could also restrict this feature to root [...]
You also said something about root-only syscalls. A root-only solution
isn't much use, because it works only for programs run by root or
running setuid-root. ld.so has no special dispensations; it runs with
the same privileges as the rest of the executable.
> Now that I'm re-thinking all of this I've realized that there would
> be no need to add any new system call features if we had mandatory
> file locking. [...] Speaking of mandatory file locking, I'd prefer
> the style where one sets a mode bit on the file [...]
Now *this* has some promise. If we added a bit that marks a file as a
shared library, then (a) ld.so can refuse to use things that aren't
shared libraries and (b) the kernel can arrange for mmapped sections on
such files to be treated like text segments.
Unfortunately if this uses the normal mode bits, it's not obvious what
bit combination to use to encode this status; if it's not part of the
normal mode bits (eg, if it's a flag bit a la chflags), then (a) many
backup programs won't back it up and (b) it won't work except on
filesystems supporting that style of flag bits.
It would be possible to record somewhere all files that are blessed as
shared libraries, but that is the /etc/shells bug all over again - if
nothing else, it breaks non-root users' ability to do their own shared
7D C8 61 52 5D E7 2D 39 4E F1 31 3E E8 B3 27 4B