From owner-freebsd-fs@freebsd.org Tue Sep 22 20:19:12 2015 Return-Path: Delivered-To: freebsd-fs@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B5F829CEDF2 for ; Tue, 22 Sep 2015 20:19:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-wi0-x230.google.com (mail-wi0-x230.google.com [IPv6:2a00:1450:400c:c05::230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5522F1918 for ; Tue, 22 Sep 2015 20:19:12 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by wicfx3 with SMTP id fx3so40951706wic.0 for ; Tue, 22 Sep 2015 13:19:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=QRjnnjnV3LGHUzo0ISLMFVYtGcUwT8mDTaa7cVUoS8s=; b=o9gsMYjflHwXrRZrr8CwUyB7GPuYkqrjxVbYGgHSCCUgyCzpFXtpJn7YOsQMwotQsL SpmvNzupWTCSg2JaHX3c1FFE9vUiuAm4joE1fPm+6CtR2cjq7kBQNUDVwMH2aHqHQ+Jg KJW2pwJ8RGylFdRT8N5TxS8O+g9dthXBJcwA0CB7Ag0ANvHEro20zixKwtEZQTxSBEUe bz9kVbcD8tLEwgXXxKUEEcT9qcuUa1JwGzXpjB4ExQukzF7uKPTc+z0qeoh9UPEbQnN6 XA90zqy/9d5DQRRd14NUpg/4C/KkNrPaJRXzJx8fIuGrGvSHvpQN7ejnCmOiy9BvQF0U pwZA== X-Received: by 10.194.52.106 with SMTP id s10mr29892958wjo.35.1442953150877; Tue, 22 Sep 2015 13:19:10 -0700 (PDT) Received: from dft-labs.eu (n1x0n-1-pt.tunnel.tserv5.lon1.ipv6.he.net. [2001:470:1f08:1f7::2]) by smtp.gmail.com with ESMTPSA id fx2sm4868592wib.24.2015.09.22.13.19.09 (version=TLSv1.2 cipher=RC4-SHA bits=128/128); Tue, 22 Sep 2015 13:19:09 -0700 (PDT) Date: Tue, 22 Sep 2015 22:19:07 +0200 From: Mateusz Guzik To: Kevin Day Cc: freebsd-fs@freebsd.org Subject: Re: Neutered devices in jails (per FS flag?) Message-ID: <20150922201907.GA27724@dft-labs.eu> References: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-fs@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Filesystems List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 22 Sep 2015 20:19:12 -0000 On Wed, Sep 16, 2015 at 11:30:33AM -0500, Kevin Day wrote: > We’re currently using jails to allow servers to copy backups of themselves to a central backup server. The problem we’re having is with mknod/devices. Currently jails don’t allow device files to be created, which makes sense - you don’t want them to be able to bypass the jail by opening /dev/kmem or something. We want jails to be able to create device files, just not be able to open/use them. > > Has anyone given any thought to changing this behavior? Allowing jails to create/manipulate device files, but not actually opening them? I.e. instead of returning EPERM on creating the device, instead return EPERM on opening it? This would likely need to be a filesystem flag, because jails still require some devices to work (a separate devfs mount or something). We could make the jail’s /dev read only or use devfs so those devices still work, but have the parent jail directory with a “noopendev” flag or something similar. > > Has anyone gone down this path before? > Let's lay down some facts to make things clear. 1. device nodes on regular filesystems are not treated as devices by the kernel 2. device visibility in devfs is controlled with appropriate rules. mknoding a device will make it appear, regardless of presence of a 'hide' rule So, mknod in question /on devfs/ would be useful to make stuff reappear if it was deleted by accident, i.e. its a nice little feature. Allowing jailed root to make explicitly hidden devices visible is a complete non-starter (regardless of whether it is allowed to use them) so this would have to be plugged. Allowing jailed root to mknod on regular filesystems by defualt is also a non-starter because said filesystems may be exported with nfs and the other party possibly forgot about nodev and actually respects device nodes. Further, you can mknod more than just a device so that would have to be audited. So, to summarize, this can be done. So what is needed for such a feature to hit the tree: 1. it would have to be an opt-in thingy (similar to how e.g. sysvipc is handled) - a trivial change 2. arbitrary device creation on devfs would have to be disabled if the user is jailed - likely a trivial change 3. someone has to audit mknod - unclear I'm not up to the task at the moment though. I'm happy to take a look at patches for 1 and 2, but I'm not committing anything without point 3 being executed (and I'm not touching it for now). -- Mateusz Guzik