From nobody Sat Mar 23 13:58:37 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 4V215712hqz5F266 for ; Sat, 23 Mar 2024 13:58:51 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-ua1-x92a.google.com (mail-ua1-x92a.google.com [IPv6:2607:f8b0:4864:20::92a]) (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 4V21556lpYz50wL; Sat, 23 Mar 2024 13:58:49 +0000 (UTC) (envelope-from asomers@gmail.com) Authentication-Results: mx1.freebsd.org; none Received: by mail-ua1-x92a.google.com with SMTP id a1e0cc1a2514c-7e0f4106a8bso345241241.1; Sat, 23 Mar 2024 06:58:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1711202329; x=1711807129; darn=freebsd.org; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=o2j5c4IEyJY6LexHgR2/c8h42TYS+TT3xDNYNAHGfKQ=; b=IysWFjUg5ggie95G1e08dQp9cwAdqR+wiFknkBa7B56Bx0N6WJ+l0hbVY0fXcT2Ltn udGmlZucRRfQZnDRhMVoR/0ggya2JeK4CW50fxuzDlaqNn5fpzx7o3mhEdp3DHBHDV7A HbytWEHnnimOMTLM9KuNTorjCfCov4xJ9Lj+uQ1sCu/Ou4hrTkOLsnKLGcBw1NzQI8UX 4yj2BCtspsgj+TZjWIaFV7Ern7i9faTNnkrJN+7PlphovpSop036HMFGpO2oBV/0TIW5 k3dJrUdwHl90QjV3VKVsvnt7mjbnQJTQzn3ULw9DoGWGm26DbD29+KMq5ltLU76F6Duy 0XZA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1711202329; x=1711807129; 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=o2j5c4IEyJY6LexHgR2/c8h42TYS+TT3xDNYNAHGfKQ=; b=RfLOICLEM1np6NchvyKcwntWmxqVemYqk+mSYiGXVUrLrMkoLcwvf+OYeajv2Yu1l/ 7SYvPyOrhzEVh2Q9R+HxFtlmfFqNUMnmWlMLOvyk7pO0VGSfBOxlEZRtQgitwVBHF6EH Z9oE5SmDSpRa0aYuT2o1rVidkSe2fVdKwvdHfv/jHp+czDdIBWq0o8Z01wNMvzPvDt82 Z3V7XzJpZQ7Dbx6+L8BrU22GnzZ7VKGIYYGnkgL02GGNexjsLkJTUHekxBrpybDYIbzF V0AOg6sj44drSzTGNQvsU7MYGJtGyJvjMTasM/dvny4SD6g4q2iyZRfw2x8uT18CoH7Z VBXg== X-Forwarded-Encrypted: i=1; AJvYcCWK2TFPlA37Bdpnv++STTul7pvzca+pUyoKPXR1cmMg4fENxJijfo2k1GQZPZNAPlN8pVv06eoKBSx2rSM4+BmIi7g5o8flBQj+2JY= X-Gm-Message-State: AOJu0Yy5mIbX7aI84pIM5SnI3y9+JQlcI1qDTMIxz58TV0XkUV0navks wrgmPluEON5iX79btO0GbdWo2+2goRQMuHy1O9U/h5bBWEqXS94LiuckXPMr4RQDmKNnaCmcRzl cpNZ5QEIXAKDxW3Q6hSjmx3f2V4TcOz32BLw= X-Google-Smtp-Source: AGHT+IHsC/EB9WPnK2NbVbNdaXcQpc+jfv/VEijStQka8a/sbzCHNNYezF+PcozBBR+SGpF6izMJ9BWU++9uRJLC2lk= X-Received: by 2002:a67:ec45:0:b0:476:d40e:2e27 with SMTP id z5-20020a67ec45000000b00476d40e2e27mr1955661vso.30.1711202329177; Sat, 23 Mar 2024 06:58:49 -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: Sat, 23 Mar 2024 07:58:37 -0600 Message-ID: Subject: Re: Filesystem extended attributes and Capsicum To: Shawn Webb Cc: Alan Somers , 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:2607:f8b0::/32, country:US] X-Rspamd-Queue-Id: 4V21556lpYz50wL On Fri, Mar 22, 2024 at 9:52=E2=80=AFPM Shawn Webb wrote: > > On Fri, Mar 22, 2024 at 08:07:17PM -0600, Alan Somers wrote: > > On Fri, Mar 22, 2024 at 6:56=E2=80=AFPM Shawn Webb wrote: > > > > > > On Fri, Mar 22, 2024 at 06:20:48PM -0600, Alan Somers wrote: > > > > 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 enabl= ed > > > > > (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 th= at > > > > > 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 cal= led: > > > > > > > > > > =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_ENA= BLED, NULL, 0); > > > > > if (sz <=3D 0) { > > > > > if (errno =3D=3D ENOATTR) { > > > > > /* > > > > > * This is okay, it just means that nothin= g has been 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_t= ype=3Dheads > > > > > > > > > > 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/harden= ed/current/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/Shaw= n_Webb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.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 th= e > > > > names of any other kernel functions that return an integer value of > > > > 93. From there, guess which function is the real source of the err= or. > > > > Then you can do > > > > > > DTrace is unavailable on this particular system. > > > > > > It does indeed fail with ENOTCAPABLE. I have the kern.trap_enotcap sy= sctl > > > set to 1 so that I can know at exactly what point we're failing, and > > > it's indeed at extattr_get_fd. > > > > > > 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_We= bb/03A4CBEBB82EA5A67D9F3853FF2E67A277F8E1FA.pub.asc > > > > Without dtrace, you've got your work cut out for you. I suggest > > simply adding all capabilities, verifying that extattr_get_fd works, > > and then removing capabilities until it fails. Or, run your program > > on vanilla FreeBSD with dtrace. > > HardenedBSD doesn't have any modifications that would affect Capsicum > in this manner. Regardless, I reproduced the problem successfully on > FreeBSD 14.0-RELEASE without any code changes. I tried running your > DTrace script on FreeBSD 14.0-RELEASE and got this output: > > =3D=3D=3D=3D BEGIN OUTPUT =3D=3D=3D=3D > $ sudo dtrace -i 'fbt:kernel::return /arg1 =3D=3D 93 && pid =3D=3D $targe= t/ {trace(".");}' -c "obj/hbsdctrl pax list /bin/ls" > dtrace: description 'fbt:kernel::return ' matched 31396 probes > aslr: sysdef > mprotect: sysdef > pageexec: sysdef > segvguard: sysdef > dtrace: pid 29270 has exited > CPU ID FUNCTION:NAME > 3 47780 foffset_unlock_uio:return . > 3 50605 foffset_lock:return . > 3 47778 foffset_lock_uio:return . > =3D=3D=3D=3D END OUTPUT =3D=3D=3D=3D > > But I'm still unsure what I'm missing, if anything. That's red herring. Those functions return void, but dtrace doesn't know it. So the "93" is just register garbage. I also notice that kern_extattr_get_fd isn't listed. Are you sure that your program is really failing with ENOTCAPABLE? You can also try running it with ktrace. kdump will show you exactly what capabilities you limited the file descriptor to. That can help you verify if you applied the limits correctly. -Alan