From owner-freebsd-hackers@freebsd.org Mon Oct 26 17:04:41 2020 Return-Path: Delivered-To: freebsd-hackers@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 30D6E449D85 for ; Mon, 26 Oct 2020 17:04:41 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: from mail-lf1-f44.google.com (mail-lf1-f44.google.com [209.85.167.44]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4CKh5h5Y66z4Txm; Mon, 26 Oct 2020 17:04:40 +0000 (UTC) (envelope-from 6yearold@gmail.com) Received: by mail-lf1-f44.google.com with SMTP id l28so13015955lfp.10; Mon, 26 Oct 2020 10:04:40 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=6Bx6fdmTM5u+gy3SlY4RQGfLEWsHNld0q/NuD7vpobk=; b=A06Kv80eSYo1VtbfW0KKvwJl9H/FSDC5G2QAhRRvyuF4Du2QmjEN/phkQLVNNIOnnr AHBkmq3ZZ+EkytKaNZBbPSFI7/6A1fvSgak0udcqw/5Vt0pMcgcWbiGJNjb57AqtNtb2 aH6froo71VxMAbTBHyh0oLDVvF+pI9csUisLxMG2CeB4YQgOn2o3cuuo4dx5uvuhz984 kcF5vKGbqQmYkugHuVwQ+1h+zGOU/Fs79Yh9qLmgzEpUCuS+o9f4KPf6NrpupyLfsJPd ISXjz658z82Mo5mhILpGjSE6JhNLkEnB14FJG6WrCMKmUTNITlm10gi9YGZcW9HJHWYQ 8/9w== X-Gm-Message-State: AOAM533HIsjjtAUh56Ifj8w2yXJD8KCy6T74FyrRLktYP/2xmEKwyzu6 GBIrOKaNLytOVL8AkXMW+p4lMHMWC/jrEA== X-Google-Smtp-Source: ABdhPJwlInujnOf1B+6256ls+vlhWjfFIoKP0gYhN49V84OjAqn5j3SIXmlM/UwhS9qFXG9x2BAUxw== X-Received: by 2002:a19:9d3:: with SMTP id 202mr6062746lfj.329.1603731878715; Mon, 26 Oct 2020 10:04:38 -0700 (PDT) Received: from mail-lj1-f175.google.com (mail-lj1-f175.google.com. [209.85.208.175]) by smtp.gmail.com with ESMTPSA id z25sm1095181lfi.132.2020.10.26.10.04.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 26 Oct 2020 10:04:38 -0700 (PDT) Received: by mail-lj1-f175.google.com with SMTP id h20so11021105lji.9; Mon, 26 Oct 2020 10:04:38 -0700 (PDT) X-Received: by 2002:a05:651c:1194:: with SMTP id w20mr6041476ljo.174.1603731878178; Mon, 26 Oct 2020 10:04:38 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Gleb Popov Date: Mon, 26 Oct 2020 21:04:11 +0400 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Mapping Linux capabilities(7) to our Capsicum rights(4) To: Jonathan Anderson Cc: freebsd-hackers X-Rspamd-Queue-Id: 4CKh5h5Y66z4Txm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; REPLY(-4.00)[] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-hackers@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Technical Discussions relating to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Oct 2020 17:04:41 -0000 On Mon, Oct 26, 2020 at 4:17 PM Jonathan Anderson wrote: > Hi Gleb, > > There won't be a clear mapping between the two, as Linux "capabilities" > (actually privileges, but unfortunately Symbian and POSIX.1e both called > their privileges "capabilities" [1]) describe things that a process can do, > whereas Capsicum capabilities (which are object capabilities) describe > things that a file descriptor can do. If you want to constrain the > behaviour of a process, Capsicum provides cap_enter(2), giving up access to > global namespaces, but that approach may not fit with the Linux-tailored > software you're porting. > > What's the fundamental security goal of the software in question? Dropping > privileges is one mechanism to try to accomplish your goal, but there may > well be a very different way of accomplishing it. In many situations (e.g., > sandboxing), Linux "capabilities" and seccomp-bpf are a bit of an awkward > fit... maybe we can help you find a better way? > It would be great, but I must admit that at the moment I barely understand all the complexities of the software. >From what I can tell, it spawns child processes and applies following hardening for them: - chroot into a sort of "jail". - prohibits using some system calls (using that seccomp thing) - drops capabilities with cap_* functions For now, I'm simply #ifdef'ing this code, but the upstream is really concerned about security and insists that all these security measures be reimplemented when making a port. I have about zero experience in this field, so any guidance would be most appreciated.