[ On Sun, May 24, 1998 at 10:30:08 (-0700), Jason Thorpe wrote: ]
> Subject: Re: a.out dynamic libraries 
>
> If you had done this to a running program, you would have gotten ETXTBSY
> when you tried to write, but since the shared library is mapped by user
> code and not the kernel exec code, the vnode doesn't have the VTEXT flag
> set (which would cause the error to be returned).

This idea is a gross and horrible hack, but may have enough utility to
give it merit:  How about a system call to set and clear VTEXT on a
file?  Better yet implement a usage counter with increment/decrement
calls and check that counter everywhere that VTEXT is checked.  Ld.so
would increment this flag on shared libraries that were in use and hooks
would be needed to decrement the counter when the libraries are
unmapped.  This call would of course be restricted to root (and maybe
to the owner of the file too).

This would have the added benefit that nobody, not even root, could
undermine the integrity of an in-use shared library (unless of course
that root user was smart enough to no-op out the counter increment call
in the run-time loader and wait for the count to be decremented while
the library was still in use, but with the system immutable flag set on
ld.so as well as all the libraries, this would make the cracker's job
much more difficult).

I'm still not sure I'd want to use shared libraries on a really critical
system, but this would indeed reduce the risk by another notch.

It would also reduce the risk of accidental damage in a development
environment because careless users would be prevented from overwriting
an in-use library just the same as they are prevented from overwriting
an in-use executable.

Speaking of the security of shared libraries...  I think I'd also like
to have an /etc/ld.so.conf option that required all shared libraries to
be owned by a specified user-id, esp. if they're in one of the specified
search path directories.

-- 
							Greg A. Woods

+1 416 443-1734      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>