From owner-svn-src-all@FreeBSD.ORG Thu Feb 6 20:53:04 2014 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 7A8D448F; Thu, 6 Feb 2014 20:53:04 +0000 (UTC) Received: from mail.ebusiness-leidinger.de (mail.ebusiness-leidinger.de [217.11.53.44]) by mx1.freebsd.org (Postfix) with ESMTP id F32C814BE; Thu, 6 Feb 2014 20:53:03 +0000 (UTC) Received: from outgoing.leidinger.net (p57A38362.dip0.t-ipconnect.de [87.163.131.98]) by mail.ebusiness-leidinger.de (Postfix) with ESMTPSA id E94CA844007; Thu, 6 Feb 2014 21:53:00 +0100 (CET) Received: from unknown (Titan.Leidinger.net [192.168.1.17]) by outgoing.leidinger.net (Postfix) with ESMTP id 576FA3469; Thu, 6 Feb 2014 21:52:58 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=leidinger.net; s=outgoing-alex; t=1391719978; bh=HV/67nblhbH2T8Xw6xG7IzvPAsCkqSukmNRmMUPDwS8=; h=Date:From:To:Cc:Subject:In-Reply-To:References; b=2jb+NucWqJuBx+4easN4VMQJ6aMLSD03k7P18uCnHLhv4wnPhmpnox+JvRUpLvupE 6YmrDaxHezOQ4R33O4L6Jt3yuShAk5NOHXT11Bf5h/IK3eJaoqZPRxhjyqGTJHS4hb s7mWqWGcUWHvtWRFX3CeQQlJitXmkoX9Pfr0YHfrUgKda40jZLmetCc90TutbECx+q la/eipZcXaHTFgemStdlfKxxzbBnklTztIhFJB5qw58uYy4VMze7FD5FrLymdwq85u CEYlSSLBwP3OToBVH+wF6Zw1zlnnEQtkrCLRO82oaioAPnH3tVOugTMz84ejtPkMy4 6F6Mq7vYm9gdg== Date: Thu, 6 Feb 2014 21:53:00 +0100 From: Alexander Leidinger To: John Baldwin Subject: Re: svn commit: r261266 - in head: sys/dev/drm sys/kern sys/sys usr.sbin/jail Message-ID: <20140206215300.000014a3@unknown> In-Reply-To: <2362081.WrjYmKeYu9@ralph.baldwin.cx> References: <201401291341.s0TDfDcB068211@svn.freebsd.org> <52EC4DBB.50804@freebsd.org> <20140203235336.GA46006@ambrisko.com> <2362081.WrjYmKeYu9@ralph.baldwin.cx> X-Mailer: Claws Mail 3.9.2-55-g74b05b (GTK+ 2.16.6; i586-pc-mingw32msvc) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-EBL-MailScanner-Information: Please contact the ISP for more information X-EBL-MailScanner-ID: E94CA844007.A5107 X-EBL-MailScanner: Found to be clean X-EBL-MailScanner-SpamCheck: not spam, spamhaus-ZEN, SpamAssassin (not cached, score=-1.096, required 6, autolearn=disabled, ALL_TRUSTED -1.00, AWL -0.07, DKIM_SIGNED 0.10, DKIM_VALID -0.10, DKIM_VALID_AU -0.10, RP_MATCHES_RCVD -0.00, TW_SV 0.08) X-EBL-MailScanner-From: alexander@leidinger.net X-EBL-MailScanner-Watermark: 1392324781.28799@Xs+Tx430iFvgJGcm2cOqYQ X-EBL-Spam-Status: No Cc: src-committers@freebsd.org, Doug Ambrisko , svn-src-all@freebsd.org, Gleb Smirnoff , Robert Watson , James Gritton , svn-src-head@freebsd.org X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.17 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 Feb 2014 20:53:04 -0000 On Wed, 05 Feb 2014 14:05:29 -0500 John Baldwin wrote: > I think having a "kmem" flag for jails is a hack and not the right > approach. It does make a jail useless security-wise, but by > masquerading as a flag, it implies that it is only partially > violating security which gives a false sense of security. I think we need to differentiate between security and safety here. The allow_kmem flag disables security (protections against a malicious program which was written specially to make use of kmem/io to do something nasty and requires much more knowledge to write) but does not allow all the other things for which we have flags (raw sockets, chflags, mount). The safety aspect comes into play when you have badly behaving programs (in the sense of bugs, stupid programmers or unwanted behavior in some parts of a program). In such a case you may want to allow kmem access, but not raw socket / ... access. Having it as a flag does not imply to me that is is only partly violating security, I think it is just a matter of wording. Either in the description of the flag, or additionally in the naming of the flag (maybe more in the sense of allow.open_backdoor?) > A short term solution that would permit non-security jails without > having to do the longer term work that Robert would like might be to > add a new per-jail flag that in effect means "no security at all". Personally I wouldn't object if we replace the kmem flag with a "no security at all" solution, I would keep the patch locally until the long term solution may or may not surface. Note: over the years I had several people which were interested in my patch. Not an overwhelming amount, but still, there are people interested in it. Bye, Alexander. -- http://www.Leidinger.net Alexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137