Date: Thu, 20 Jul 2000 13:05:44 -0400 (EDT) From: Robert Watson <rwatson@FreeBSD.org> To: Marcel Moolenaar <marcel@cup.hp.com> Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org, security-officer@FreeBSD.org Subject: Re: cvs commit: src/sys/i386/linux linux_dummy.c linux_misc.c Message-ID: <Pine.NEB.3.96L.1000720125351.85018B-100000@fledge.watson.org> In-Reply-To: <39768878.3D899AC@cup.hp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 19 Jul 2000, Marcel Moolenaar wrote: > > If the answer to either of these questions is no, I'd like to see this > > backed out before the release. > > If there's a shift in how we treat Linuxulator security issues, I'd like > it to be discussed first. If any of the security officers decides after > looking at the code that the implementation is too dangerous, I'll back > it out. I guess the open question here is what path in the emulator provides us with the greatest correctness of emulation while maintaining a safe and rigorous (and consistent) security stance. Emulating security semantics is a nightmare, and I think there are some situations where it's ok to kludge, and some where it is not. For example, it may be that we authorize certain types of signaling behavior differently, or allow activities in the port space that linux might not. I do not see this as a problem. On the other hand, we do want to make sure that if privileged applications are running, they see the behavior they expect, preventing them from acting incorrectly and possibly relinquishing rights to unprivileged users that they should not. This effects both setuid and privileged daemons. (1) Do we need to support linux programs running with privilege that attempt to manipulate their rights (calls to setuid/gid/fsuid/fsgid/capability). This is not the same as supporting ls for uid 0. (2) If we do, what assumptions to Linux applications make that may or may not be safe in our environment. I.e., some of our uid/gid handling probably is the same (although you have to be really careful here due to posix saved uids/gids), and can we let the application use that? (3) For that behavior is not the same, how can we provide that information to the application, or prevent a problem. This is an important case, because this is where the sendmail bug occurred on Linux. In Linux, the setuid() call is now permitted to fail even if the effective uid is zero. In a few months, the same will be true of FreeBSD. However, the sendmail application assumed that setuid() would always succeed, and so didn't check the error return. Do linux applications check the return for, say, setfsuid()? Right now, is our behavior to kill the application? That's certainly fail-safe, although not fail-happy. If we choose not to support that type of behavior because we cannot safely emulate it, we need to document that and make sure it doesn't interfere with our desired application emulation base. We're only going to have more questions like this to answer in the future: more and more privileged linux applications will make use of the capabilities interface (we have the interface, but not implementation, committed right now). We really don't have an equivilent of the fsuid, although to some extent we could fake it through appropriately wrapping file system calls (not really very safe, but could work relatively well). Whatever route we choose, we need to make sure that linux applications cannot violate system integrity policies, or behave in "unexpected" ways that could result in compromise. A short-term answer might be to refuse execution of setuid emulated binaries on disk, and kill applications making uid-manipulation calls (but emulate relatively well the inspection calls). I assume you introduced these calls to support a specific application or application class. If you don't mind, what applcation is that, and do you feel that supporting that application is necessary? (i.e., could we port it to FreeBSD, or is it a binary-only Linux program). And for reference, this concern applies to the other emulators also. The BSD/OS one I feel more comfortable about, as our semantics should already be largely the same (auditing would still be a good idea), but SysV and so on will require similar contemplation. Robert N M Watson robert@fledge.watson.org http://www.watson.org/~robert/ PGP key fingerprint: AF B5 5F FF A6 4A 79 37 ED 5F 55 E9 58 04 6A B1 TIS Labs at Network Associates, Safeport Network Services To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.NEB.3.96L.1000720125351.85018B-100000>