From nobody Thu Feb 10 09:13:07 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id B00E719C4649 for ; Thu, 10 Feb 2022 09:13:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JvWHn12b0z4sT6; Thu, 10 Feb 2022 09:13:09 +0000 (UTC) (envelope-from theraven@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644484389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YyapbXwnQY0iyKVa9SFMzZ8e3/dX0PYU/nahnmRab9I=; b=rL4uraoWRFqAbq/snjyhm0Jv+dJueXCzHgbqKcTp5vTJ+0z0BgLJS54N+5BzIL7fOoEUc6 74c+cR35cBwFsgqoysL/FcBIAYkXS5f6wGdZ8VOdddnYL3hU7ntnKrqjSmAtJppicN5kJ9 koTaTHqRnhttV0E9Rqag2YjszIKciMDVbIOk+S9vlHj3Bh0W9jjGOzJa211JP2ODEF2JpG PQ35wiIh3xCks5SsNpRKr3ruySzSlcF0Kn69ooL0jLPuGe6gM+rhMmtHEio54KUl4nOTtT a9/DLx6erpGLCcxJ3eRGZr3VrZnjYCeocXSpLO28ZGH6sWfm5nPR8Zpe4RSELA== Received: from smtp.theravensnest.org (smtp.theravensnest.org [45.77.103.195]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: theraven) by smtp.freebsd.org (Postfix) with ESMTPSA id C5FE62DAE1; Thu, 10 Feb 2022 09:13:08 +0000 (UTC) (envelope-from theraven@FreeBSD.org) Received: from [192.168.1.64] (host86-134-184-31.range86-134.btcentralplus.com [86.134.184.31]) by smtp.theravensnest.org (Postfix) with ESMTPSA id E8D9E2EFF9; Thu, 10 Feb 2022 09:13:07 +0000 (GMT) Content-Type: text/plain; charset=utf-8 List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.120.23.2.7\)) Subject: Re: how to restrict file access below some top directory From: David Chisnall In-Reply-To: Date: Thu, 10 Feb 2022 09:13:07 +0000 Cc: freebsd-hackers@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <7DAD732E-BCE7-4D3A-B259-418FFA70BBC1@FreeBSD.org> References: To: Matthias Apitz X-Mailer: Apple Mail (2.3608.120.23.2.7) ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1644484389; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=YyapbXwnQY0iyKVa9SFMzZ8e3/dX0PYU/nahnmRab9I=; b=x+Zex9fylLUnaYF9697GfSd/oaQ53H/B8ITPGSU9uSqcDXqGccfbs4xiyNbm76OcUqSU81 UQnVTsVRsy0kdeixaWFu44vi41Yh4+BfJ27h9iz1Vv4vLtx+pNekvb3aVu0oErNYC1oSTs uu227+kx9e6iWtRWmiBQyWVz3QZkTAJW0LpaiFK/BiLk/p7ZPLbt92FaWWEWZMo7w4ET/d WTDmEjEv83eCX0TU2XjcB7HSzGm+jnB6CF1ZJpC+DNWnDt1d7s7Pycg7xUYQ9D+Ct7nUjY 6JxzB+eU8m7BPviiSKpOM5CN4fzNak1VVLdSmf2FgvE5D0IZu7d6sACsfYBv8A== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1644484389; a=rsa-sha256; cv=none; b=Y01ijCTa5dpm4iLydFUiKHTKkduXQw11A2K+g9iixMztMJHRRfy8P3/DxIOriGI/otcHJE FhqZcbhDYzqpwIlQHNsO0UGnGfpf2CbD4SJLYAhG73SrL0TviJ+/VS/m85go2UYOxTjJx+ mGZlwbFLDpdFFY07VPSD4m4RQ7vknvRWK5LENSP0cBHZUWMPORD7hl1TLeQ7F/5oF+tfzK m/1/ert99bzOSeedWHKnx20ssWSQQcbFnBQ5n5xwd+/rjgQq90WiWorawemwZF1gbQ+AgV SaXXljezhR7c/rgxTuskSqN8LB6n2bmMzkzh01vxg8loFuSEGfVHyBd3c0KxuA== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N Hi, > On 10 Feb 2022, at 08:25, Matthias Apitz wrote: >=20 > I want restrict in a C- or Perl-written application the file access to > only files below some top directory, say >=20 > /var/spool/dir/ >=20 > and not allowing, for example, access to = /var/spool/dir/../../../etc/passwd > Ofc, this could be done easy with chroot(2), but this would require = root > permision. Any other ideas? There are (at least?) four ways of doing this with FreeBSD: You can use chroot. This provides a simple redefinition of the root of = the filesystem. All dependencies (shared libraries and so on) must be = below the new root. You can use nullfs mounts to set up this hierarchy = to include read-only views of existing things (such as /lib, /usr/lib). = Note that chroot doesn=E2=80=99t restrict anything other than the = filesystem namespace. SysV IPC, sockets, and so on are unrestricted. = Note that you must be root to enter a chroot, but root can fairly easily = escape from the chroot, so you need to setuid after entering it. You can use a jail: https://docs.freebsd.org/en/books/handbook/jails/ This has the same set of requirements as a chroot (the process can=E2=80=99= t access anything outside of the new root, so the new root must have all = support files needed) but gives you a much more complete environment. = You can restrict access to the network and other IPC namespaces to the = jail and you can also have multiple user accounts inside. Root in a = jail is not the same as root outside and (modulo kernel bugs), root in = the jail can=E2=80=99t escape, so it=E2=80=99s safe to run things as = root in the jail. You can write a MAC policy that restricts access to the hierarchy:=20 https://docs.freebsd.org/en/books/handbook/mac/ This has the advantage that it=E2=80=99s non-invasive and makes it = possible to poke holes in the restriction for things like shared = libraries but writing the policy can be complex. The BSD Extended MAC = policy provides firewall-like rules that let you constrain a user to a = subset of the filesystem, which is probably the simplest way of writing = this kind of policy. https://www.freebsd.org/cgi/man.cgi?query=3Dmac_bsdextended You can use Capsicum: https://www.freebsd.org/cgi/man.cgi?query=3Dcapsicum This requires source-code modification. Once you call `cap_enter`, you = have no access to any global namespace (filesystem, IPC, network, and so = on) but if you=E2=80=99ve opened /var/spool/dir then you can use = `openat` to open files below that location in the filesystem namespace. = You can also apply fine-grained restrictions to file descriptors (for = example, granting read-only access to certain directories or append-only = access to certain files). We=E2=80=99re using this in Verona with a = lightweight RPC mechanism to invoke untrusted shared libraries and proxy = any calls to access things in the global that they need (open, connect, = bind) to the parent process, which can enforce policy. David