[EMAIL PROTECTED] (Bruce Perens) writes:
> We don't want to have more than one instance of a library in the
> filesystem if that is at all possible. We currently violate this for
> anonymous FTP, which has its own copy of a few system utilities and
> its own copy of the C shared library. I notice t
[EMAIL PROTECTED] (Bruce Perens) wrote on 16.10.97 in <[EMAIL PROTECTED]>:
> The best way to deal with this would be some sort of filesystem hack under
> the chroot-ed directory.
What would be needed would be a way to read-only access specified parts of
the outside filesystem, preferrably with
From: Topi Miettinen <[EMAIL PROTECTED]>
> If we had a fexec(int fd,..) [...]
> I don't know how dynamic libs would be dealt with, though.
Not easily. What I want to do is to have a list that is made into a
filesystem in the chroot environment, but uses the same device/inode pairs
as the underlyi
From: Topi Miettinen <[EMAIL PROTECTED]>
> But if the libraries are not hard linked (that probably would be ruined in
> update), I believe they would still be in memory more than once, because
> they then had different inodes and the OS would have no way of knowing they
> are the same.
We don't wa
From: [EMAIL PROTECTED] (Richard Braakman)
> It might be even easier to link the daemon statically.
No, the small security or filesystem integrity gain of using a static-linked
binary is not worth the cost of having a second copy of libraries in its
working set. The developers have discussed this
> It might be even easier to link the daemon statically. It's not going to
> be able to share its libraries with any other program anyway.
Linking them statically may open other security holes: there are
bugs found in the libraries. Fixing the libc bugs will then also
require the system admin to
It might be even easier to link the daemon statically. It's not going to
be able to share its libraries with any other program anyway.
Of course, that means that sites that want that kind of security will have
to compile the daemons themselves. I expect that they'll want to do that
anyway. If I
Before you run a shared-library program in a chroot context, you need to
provide the shared libraries in that context. It's easier to have the
daemon chroot itself after it's already been loaded. It's also nice to
have the daemon drop root privileges, but it's not always possible.
Bruce
--
One way to limit damage caused by a daemon with an exploited security
hole is to run it in "jail", chrooted environment. An example is DNS:
http://www.homeport.org/~adam/dns.html
The same mechanism could be used with several other daemons which
do not need to access files outside their running dir
9 matches
Mail list logo
