From nobody Fri Apr 14 23:57:08 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 4Pytg30S5qz45557 for ; Fri, 14 Apr 2023 23:57:51 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Received: from sdaoden.eu (sdaoden.eu [217.144.132.164]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Pytg10rbwz3Fb6; Fri, 14 Apr 2023 23:57:49 +0000 (UTC) (envelope-from steffen@sdaoden.eu) Authentication-Results: mx1.freebsd.org; dkim=none; spf=pass (mx1.freebsd.org: domain of steffen@sdaoden.eu designates 217.144.132.164 as permitted sender) smtp.mailfrom=steffen@sdaoden.eu; dmarc=none Date: Sat, 15 Apr 2023 01:57:08 +0200 Author: Steffen Nurpmeso From: Steffen Nurpmeso To: Steffen Nurpmeso Cc: Ed Maste , freebsd-hackers@freebsd.org Subject: Re: capsicum(4): .. and SIGTRAP causing syscall really is in siginfo_t.si_errno? Message-ID: <20230414235708.gNy-c%steffen@sdaoden.eu> In-Reply-To: <20230413204117.T906W%steffen@sdaoden.eu> References: <20230412144921.8plun%steffen@sdaoden.eu> <20230412203438.IcwD7%steffen@sdaoden.eu> <20230413204117.T906W%steffen@sdaoden.eu> User-Agent: s-nail v14.9.24-443-gb34bfaf135 OpenPGP: id=EE19E1C1F2F7054F8D3954D8308964B51883A0DD; url=https://ftp.sdaoden.eu/steffen.asc; preference=signencrypt BlahBlahBlah: Any stupid boy can crush a beetle. But all the professors in the world can make no bugs. X-Spamd-Result: default: False [2.36 / 15.00]; MID_CONTAINS_FROM(1.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; NEURAL_SPAM_MEDIUM(0.94)[0.944]; NEURAL_HAM_LONG(-0.89)[-0.890]; NEURAL_SPAM_SHORT(0.60)[0.603]; R_SPF_ALLOW(-0.20)[+a]; MIME_GOOD(-0.10)[text/plain]; FROM_EQ_ENVFROM(0.00)[]; RCVD_COUNT_ZERO(0.00)[0]; R_DKIM_NA(0.00)[]; MLMMJ_DEST(0.00)[freebsd-hackers@freebsd.org]; ARC_NA(0.00)[]; ASN(0.00)[asn:15987, ipnet:217.144.128.0/20, country:DE]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_SOME(0.00)[]; DMARC_NA(0.00)[sdaoden.eu]; FROM_HAS_DN(0.00)[]; MIME_TRACE(0.00)[0:+] X-Rspamd-Queue-Id: 4Pytg10rbwz3Fb6 X-Spamd-Bar: ++ X-ThisMailContainsUnwantedMimeParts: N 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 P.S.: as an addendum. Steffen Nurpmeso wrote in <20230413204117.T906W%steffen@sdaoden.eu>: |Ed Maste wrote in | : ||On Wed, 12 Apr 2023 at 16:34, Steffen Nurpmeso wrote: ... ||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. ... I changed the program in that, on FreeBSD, configuration reload after SIGHUP is only performed in --untamed mode (no OS sandbox, only generic setrlimit(2)). Like this i can tighten the capsicum(4) sandbox in that (instead) only a descriptor to our --store-path is open, an actual "chroot" thus (we chdir(2) to that on startup). 'Allowed to get rid of all realpath(3) etc (of course), all special path treatment is gone. P.P.S.: i learned quite a bit the last weeks. postfix for example does not use anything such (except a bit setrlimit), but i trust it. I do not know. I think next time i have to bite the bullet and design it with such a supercapable process from the start. Ah, is all that expensive! Compared to strict manager / worker thread scheme with almost no shared data, thread-specific memory etc etc. I was really wondering how the usage of TLS aka OpenSSL fits this, if workers are capsicum(4)ized; they need to access CA files / directories, and, hm, private keys. I saw ressl commit messages fly by with "in-memory-images", years ago, but i never really looked. That is the thing that i wonder of, all the libraries that i have to use, how does this fit such a security scheme. All black boxes, all/most evolving targets that can change at any time. Ciao, and a nice weekend i wish! And thanks again. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)