Date: Wed, 12 Apr 2023 22:34:38 +0200 From: Steffen Nurpmeso <steffen@sdaoden.eu> To: Ed Maste <emaste@freebsd.org> Cc: freebsd-hackers@freebsd.org Subject: Re: capsicum(4): .. and SIGTRAP causing syscall really is in siginfo_t.si_errno? Message-ID: <20230412203438.IcwD7%steffen@sdaoden.eu> In-Reply-To: <CAPyFy2Do80xZmNFdtG=xbRuscKaQQM7rQ5ir5TVZENX3UfyKtg@mail.gmail.com> References: <20230412144921.8plun%steffen@sdaoden.eu> <CAPyFy2Do80xZmNFdtG=xbRuscKaQQM7rQ5ir5TVZENX3UfyKtg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello! Ah, oh!! Ed Maste wrote in <CAPyFy2Do80xZmNFdtG=xbRuscKaQQM7rQ5ir5TVZENX3UfyKtg@mail.gmail.com>: |On Wed, 12 Apr 2023 at 10:49, Steffen Nurpmeso <steffen@sdaoden.eu> wrote: |> I am trying to capsicumize a simple daemon (for learning purposes |> as that runs only in the second line behind postfix), and i have ... |Excellent, always happy to see folks exploring Capsicum. | |Keep in mind that Capsicum and pledge/unvil are not equivalent, so |comparing the ease of applying one or the other isn't particularly |meaningful. Achieving similar security properties with pledge/unveil |as with Capsicum requires similar effort in decomposing and |refactoring existing applications. Luckily not this simple thing. (With unveil together pledge seems pretty good, despite the many system calls i get, and of course the path fixation that does not allow users to add new paths when they reload configurations .. the way the program is designed; i like that new syslog system call which avoids all the things GNU C lib for example does and potentially needs, later maybe more. 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.) 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"? |> Anyhow. Regardless of 13.1-i386 or 12.2-amd64 (despite |> no_new_privs) i only see |> |> capsicum(4) violation (syscall 93, 4, 5, 0); please report this bug | |I'm not sure what you mean in the subject with respect to the syscall |in siginfo_t.si_errno. It looks like this is ENOTCAPABLE, which means This is a misunderstanding!! I *thought* PROC_TRAPCAP_CTL_ENABLE saying "the si_errno member of the siginfo signal handler parameter is set to the syscall error value" meant the actual "syscall number"! And since git head now has that _capsicum._syscall member i thought *that* would now be an explicit thing "to detangle that". It really is an error number! I did not even think about that! So .. the actual syscall number is not available in that siginfo_t before FreeBSD 14? I guess you guys simply write one of those dtrace snippets to get over that. (You know i did not even think, because the Linux seccomp(2) thing i did like that, though there it is SIGSYS and the syscall is in si_syscall. 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.) |an attempt to perform an operation on an fd that you are not allowed |to do - for example, calling write() on an fd which has had |cap_rights_limit() applied without CAP_WRITE. errno 94 is ECAPMODE. Ah yes! Not a thought on error values. |This could be for example trying to use open() in capability mode, |which is just not permitted (openat() is). Yes. I have had real problems with that, or rather that FDCWD is not possible. (And realpath did cause violations, in at least 12.2, .. though yesterday evening the program was in terrible state on FreeBSD.) |> This takes the usual shortcut of only sandboxing the last input file. |> It's a first cut and this program will be easy to adapt to sandbox \ |> all |> files in the future |> |> from a December 2016 commit message, and i like the word "easy". | |cap_fileargs() didn't exist in December 2016 and there was not yet a |straightforward, performant and desirable way to apply Capsicum to |existing applications that operate on a list of files provided on the |commandline. | |For a more recent change that makes use of cap_fileargs a good example |commit is: | |commit 802c2095b5a6dcf0f63c473cbba1e40445e9052a |Author: Mark Johnston <markj@FreeBSD.org> |Date: Thu Aug 1 18:57:08 2019 +0000 | | Capsicumize readelf(1). | | Reviewed by: oshogbo | Sponsored by: The FreeBSD Foundation | Differential Revision: https://reviews.freebsd.org/D21108 I had the impression that casper uses a supervising process. You know, then i thought i better do it myself: this allows the Linux seccomp(2) program for the clients and the server to be streamlined; not only for this small one, where that bystanding process only logs; ie, i simply sliced that into the server, and the server then forks again so that logger actually can synchronize on the server via SIGCLD (etc etc etc), and thus can inherit file locks, naturally, etc etc. --End of <CAPyFy2Do80xZmNFdtG=xbRuscKaQQM7rQ5ir5TVZENX3UfyKtg@mail.gmail\ .com> Thank you. --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)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20230412203438.IcwD7%steffen>