From nobody Thu Apr 13 18:19:10 2023 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 4Py7C02tv5z45ZTm for ; Thu, 13 Apr 2023 18:19:24 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Received: from mail-lf1-f54.google.com (mail-lf1-f54.google.com [209.85.167.54]) (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 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4Py7C00t81z4N2J for ; Thu, 13 Apr 2023 18:19:24 +0000 (UTC) (envelope-from carpeddiem@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-lf1-f54.google.com with SMTP id o1so20349307lfc.2 for ; Thu, 13 Apr 2023 11:19:24 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1681409962; x=1684001962; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=evzTCIHQx/DLt0yGx5q62S8Br0DvUO15UnJzkpWBUlI=; b=Bvmkw3ZgAqkBaBu1lkGH2m05ZW1UCRD8XwlyBuWjPfG2QrEzNzFuyMhKmGK5D+O5Zz iDbDuzPHC0EWZFHDwvxuuNgAAJHg0gz/2byFmdHAmM8BXy58nKfqt0KkhHVZT2zujcrT cgV+kCL0lWxzbpKjlOqU6893qNswpW/A5+1gL4K6rXIcl+3YxH/IC9Tc5Bvs+ngSmHbX FbcPoSCe3EKD8Se197JwX9XfTxYLhna85Ay5RJYh16+/PTKCo0Je1gQm5se1YD7FUNUq nuZAWfgJQStOER9bWqdp+cNyONqu2Zln/uQa2WUB6JS1l9g9lRMrXQSP3fWuyB1KDwGI x1Dg== X-Gm-Message-State: AAQBX9eqmcIpCcVM/0xN3ahhGXw/two9zLPVt7wOGl6qPDtsg5U9L6eS 1UZkTREqRUsNCoGAbc62lEc9LhYCkQFtso86Pi6Z2TWjJ5M= X-Google-Smtp-Source: AKy350Z1ponsA8b6BTh0azWIct7cYXbcoLF5L22teJCnvOkzizzOakakpGZSFCn3VLVSlsdMyxlCuSL7T5o7Ae6yGSE= X-Received: by 2002:ac2:522e:0:b0:4eb:a8c:5f22 with SMTP id i14-20020ac2522e000000b004eb0a8c5f22mr1048940lfl.5.1681409962038; Thu, 13 Apr 2023 11:19:22 -0700 (PDT) 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 References: <20230412144921.8plun%steffen@sdaoden.eu> <20230412203438.IcwD7%steffen@sdaoden.eu> In-Reply-To: <20230412203438.IcwD7%steffen@sdaoden.eu> From: Ed Maste Date: Thu, 13 Apr 2023 14:19:10 -0400 Message-ID: Subject: Re: capsicum(4): .. and SIGTRAP causing syscall really is in siginfo_t.si_errno? To: Steffen Nurpmeso Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4Py7C00t81z4N2J X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Wed, 12 Apr 2023 at 16:34, Steffen Nurpmeso wrote: > > I think capsicum is very, very smart and capable, like CloudABI > was. Yet very hard to work with as it needs so many new *at(), > needs to have hooks to modify descriptors after accept(), and > openat(), etc. And needs user-path <> realpath(3) mappings .. the > way i do it.) Indeed. These limitations all stem from the properties that give Capsicum its security properties (no access to global namespaces or ambient authority). It is "relatively" straightforward to use when incorporated into new software from the beginning, but certainly harder to retrofit. realpath is an interesting case, as in capability mode there is no absolute root directory. All paths are necessarily relative to a directory fd. The Casper fileargs service provides a realpath replacement, but I've also started looking into what a Capsicum-native realpathat would be. > As i am very new with this -- am i correct assuming that once > a capability was set on a directory or listening socket, opened > / accepted FDs inherit the capability of "their parent"? In general, yes. Rights can be removed or subsetted but not added. > The capsicum(4) and rights(4) etc manuals are > complete, but for someone without any real foreknowledge they miss > some small hints, here and there. Not that Linux does that > better. Or OpenBSD, where you need at least one unveil with "some > meat" in order to apply it, even if you simply want no paths at > all. .. I think.) I think capsicum(4) in particular could use more information, but man pages are always going to be closer to reference material. The initial Capsicum paper is a good read to understand Capsicum's design and approaches that can be taken to refactor existing software: https://www.cl.cam.ac.uk/research/security/capsicum/papers/2010usenix-security-capsicum-website.pdf > I had the impression that casper uses a supervising process. I wouldn't describe it as a "supervising process", but Casper does indeed involve additional process(es). In essence Casper services are performing the same work that an explicitly privilege-separated process would do. With cap_fileargs for example you have one process (that is not operating in capability mode) with access to the filesystem (global namespace). That process opens files, and passes file descriptors to the capability-mode process that performs the work.