Date: Fri, 21 Jul 2000 02:17:45 -0700 (PDT) From: Kris Kennaway <kris@FreeBSD.org> To: Marcel Moolenaar <marcel@cup.hp.com> Cc: Warner Losh <imp@village.org>, Robert Watson <rwatson@FreeBSD.org>, security-officer@FreeBSD.org, emulation@FreeBSD.org Subject: Re: Linuxulator and security [was: Re: cvs commit: src/sys/i386/linux linux_dummy.c linux_misc.c] Message-ID: <Pine.BSF.4.21.0007210201010.97490-100000@freefall.freebsd.org> In-Reply-To: <39773DB3.D12C43C9@cup.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, 20 Jul 2000, Marcel Moolenaar wrote:
> Doing the same, but only more secure should not introduce breakages. The
> point is that you either won't be able to emulate or have to pay a
> performance penalty. The former prevents applications to run if they
> happen to use or depend on un-emulatable syscalls, the latter influences
> the usability of the Linuxulator at large. We have to be careful in our
> quest to make the Linuxulator secure that we do not render it useless
> due to a reduced application base and/or poor performance.
I think the discovery of the setfs[ug]id thing surprised a number of us on
the security side of the fence. Speaking for myself, I'd like to have
*any* linuxulator behaviour which might affect system security demarcated
by sysctls (preferably defaulting to 'off' if they don't affect the
majority of users) and their effects clearly documented so administrators
know what the side-effects of enabling them are.
For starters, I think a sensible thing to do would be to introduce a
sysctl controlling the ability of non-native binaries to run with
privileges (i.e. set[ug]id) - as Robert has noted, there are subtle
differences between the security models of FreeBSD and other systems we
emulate, and a foreign binary may fail in creative ways if it runs on a
FreeBSD system and bumps into these different semantics. This isn't really
an issue unless the binary is running with privileges (e.g. a setuid
binary, or daemon running as root, etc).
Unfortunately, it's probably not going to be easy to address this without
modifying the kernel security models to (conditionally, of course)
implement the emulated system's model precisely. It's something which
needs to be carefully examined by contrasting the semantics of the Linux
(or SVR4, or whatever) model with the FreeBSD model.
Kris
--
In God we Trust -- all others must submit an X.509 certificate.
-- Charles Forsythe <forsythe@alum.mit.edu>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-emulation" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0007210201010.97490-100000>