From nobody Sat Mar 23 00:20:48 2024 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 4V1fxW1Jh5z5FkDh for ; Sat, 23 Mar 2024 00:21:03 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-vk1-f176.google.com (mail-vk1-f176.google.com [209.85.221.176]) (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 4V1fxT5lhMz4XC8 for ; Sat, 23 Mar 2024 00:21:01 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-vk1-f176.google.com with SMTP id 71dfb90a1353d-4d43ec959f8so810007e0c.1 for ; Fri, 22 Mar 2024 17:21:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711153260; x=1711758060; h=content-transfer-encoding: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=ftqntQhsAY0a0LyNc3x1rxsNLlXVLNShqSARsZY5DfU=; b=WvISKt5UDzvK5b3oFkrHrbJib1i6cBkZO7zTV9xkrr7WUVcBUDCRla5eJZb7LMz7Wp 9GqihRI3TviFFwT6i2Z/TJoYXbomRgJnBUoUeM0ArIVPCPY3PBmTI+KHsDMABThKfIh5 gU98oyYQ+IwtdRuWDfWNtZrxkqvmnbggoIWEcJpx2P/Rg45WuNf28i0Y8O68qn4wBG0n jnYeYAUt1xotZ8/WDwVhh0MkoPAiItRivzu1HUigPm3OKgF3b8w2GA3W/IVI7EaQz3sf yagRK0f1GlQkUVbOMyWuFcPBMvpSXqC2EFTYRWKXVSfltJhaNqBkSAFSDB8WGd6yTZUr G0kg== X-Gm-Message-State: AOJu0YwocDxefWXpu2Fl6Lp5F81/7tbPjTcGNkm5PfNWD4s7ot2IzB4H iJWeIbT6CzmhBKcILS+6VnoxXEkuhb5tzGKRhL/6WMEzSKz6kww9oYvhKn0DzIy7oss82dzAX7R +DXQ8Kr5BD4oP9KQVg3gwXnoMU7hE/L9RhNE= X-Google-Smtp-Source: AGHT+IHOctoYpHNKPPE53jFhcmQx3mr5J6P9k9k6G10tdp+LzAiYhcI2HAvoc+w+68WbGJXxgAMOQp8axOjN775Br1g= X-Received: by 2002:a05:6122:1a98:b0:4d4:21cc:5f4f with SMTP id dy24-20020a0561221a9800b004d421cc5f4fmr850395vkb.11.1711153260631; Fri, 22 Mar 2024 17:21:00 -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: In-Reply-To: From: Alan Somers Date: Fri, 22 Mar 2024 18:20:48 -0600 Message-ID: Subject: Re: Filesystem extended attributes and Capsicum To: Shawn Webb Cc: freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spamd-Bar: ---- X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated 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-Queue-Id: 4V1fxT5lhMz4XC8 On Fri, Mar 22, 2024 at 5:38=E2=80=AFPM Shawn Webb wrote: > > Hey all, > > I'm writing an application in which I hope to enable Capsicum. I'm > experiencing an issue whereby extattr_get_fd fails with a file > descriptor that has all the extended attribute capabilities enabled > (CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, CAP_EXTATTR_LIST, and > CAP_EXTATTR_SET). > > Looking at the kernel source (sys/kern/vfs_extattr.c) tells me that > kern_extattr_get_fd only requires CAP_EXTATTR_GET. > > So I'm a bit puzzled as to why my call to extattr_get_fd(2) is > failing. Am I doing something wrong or are filesystem extended > attributes not supported in a Capabilities-enabled process? > > Here's how I'm creating the file descriptor (before calling > cap_enter(2)): > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > static int > open_file(const char *path) > { > cap_rights_t rights; > int fd; > > fd =3D open(path, O_PATH | O_CLOEXEC); > if (fd =3D=3D -1) { > return (-1); > } > > memset(&rights, 0, sizeof(rights)); > cap_rights_init(&rights, CAP_EXTATTR_DELETE, CAP_EXTATTR_GET, > CAP_EXTATTR_LIST, CAP_EXTATTR_SET); > cap_rights_limit(fd, &rights); > > return (fd); > } > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > Eventually, after calling cap_enter(2), the following code is called: > > =3D=3D=3D=3D BEGIN CODE =3D=3D=3D=3D > #define ATTRNAME_ENABLED "hbsd.pax.aslr" > sz =3D extattr_get_fd(fd, ctx->hc_namespace, ATTRNAME_ENABLED, NU= LL, 0); > if (sz <=3D 0) { > if (errno =3D=3D ENOATTR) { > /* > * This is okay, it just means that nothing has be= en set. > * No error condition here. > */ > return (RES_SUCCESS); > } > return (RES_FAIL); > } > =3D=3D=3D=3D END CODE =3D=3D=3D=3D > > For reference, the program's code is here: > https://git.hardenedbsd.org/shawn.webb/hbsdctrl/-/tree/main?ref_type=3Dhe= ads > > The library code, which is what's responsible for calling the > filesystem extended attribute related syscalls is here: > > https://git.hardenedbsd.org/hardenedbsd/HardenedBSD/-/tree/hardened/curre= nt/hbsdcontrol-v2/lib/libhbsdcontrol?ref_type=3Dheads > > From the rights(4) manual page, I'm instructed all I need are to apply > those capabilities to that file descriptor: > > =3D=3D=3D=3D BEGIN PASTE =3D=3D=3D=3D > CAP_EXTATTR_DELETE Permit extattr_delete_fd(2). > > CAP_EXTATTR_GET Permit extattr_get_fd(2). > > CAP_EXTATTR_LIST Permit extattr_list_fd(2). > > CAP_EXTATTR_SET Permit extattr_set_fd(2). > =3D=3D=3D=3D END PASTE =3D=3D=3D=3D > > So I'm a bit unsure if I'm doing something wrong. > > Thanks, > > -- > Shawn Webb > Cofounder / Security Engineer > HardenedBSD > > Tor-ified Signal: +1 303-901-1600 / shawn_webb_opsec.50 > https://git.hardenedbsd.org/hardenedbsd/pubkeys/-/raw/master/Shawn_Webb/0= 3A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc What error code does it fail with? If it's ENOTCAPABLE, then I suggest using dtrace to find the reason why it fails. Do something like this: dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $target/ {trace(".");}' -c ./my_application That will print the name of every non-inlined kernel function that returns ENOTCAPABLE during your process. But it will also print the names of any other kernel functions that return an integer value of 93. From there, guess which function is the real source of the error. Then you can do dtrace -i 'fbt:kernel:some_function:return /arg1 =3D=3D 93 && pid =3D=3D $target/ {stack();}' -c ./myapplication to get more information. -Alan