From nobody Wed Sep 04 15:44:13 2024 X-Original-To: freebsd-security@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 4WzRck0FkDz5V7Cl for ; Wed, 04 Sep 2024 15:44:22 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Received: from mail.w13.tutanota.de (mail.w13.tutanota.de [185.205.69.213]) (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-signature ECDSA (P-256) client-digest SHA256) (Client CN "mail.tutanota.de", Issuer "Sectigo ECC Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4WzRcj4m07z4RYj for ; Wed, 4 Sep 2024 15:44:21 +0000 (UTC) (envelope-from henrichhartzer@tuta.io) Authentication-Results: mx1.freebsd.org; none Received: from tutadb.w10.tutanota.de (w10.api.tuta.com [IPv6:fd:ac::d:10]) by mail.w13.tutanota.de (Postfix) with ESMTP id 31D031D37B04; Wed, 4 Sep 2024 17:44:13 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; t=1725464653; s=s1; d=tuta.io; h=From:From:To:To:Subject:Subject:Content-Description:Content-ID:Content-Type:Content-Type:Content-Transfer-Encoding:Content-Transfer-Encoding:Cc:Cc:Date:Date:In-Reply-To:In-Reply-To:MIME-Version:MIME-Version:Message-ID:Message-ID:Reply-To:References:References:Sender; bh=GbtzfycO97u4+FI0lhwMFeA5JkqYiv+PHZziPwrEb+k=; b=e2OjVulHDKU9sFNiEMFFcIOwoEeTIBJ5DkWXOTwFUZGkQx7JnRVX3JMfsnzc5vIe jqU+2gllchnQdnQf4Z/fdtbejMGG5TBEgfQhF6vWvOUEcEUhAr59kYfvrjvvDXndVSl 3MG/0dSrruMtNL+8tqBsFKDe+HCitgY5YZSf2x78HJjJMumGsHsqsrcVUid7oHNf0JF FqyP1uM55sVa9bTsgAXwktoTI14JQUz9a6eDX2ihCUMrwO99vlyNJ+uduwskhRk05iy qXzHrVL8htLuWkCotqQjQF6j2abm9hJ4eiMona4zjaFmXD/HcwtJEekNZokJ6OwmB3f AKmCopkZjQ== Date: Wed, 4 Sep 2024 17:44:13 +0200 (CEST) From: henrichhartzer@tuta.io To: Jan Behrens Cc: Freebsd Security Message-ID: In-Reply-To: <20240904104147.8c1e74632b2c6d4f6a759ee6@magnetkern.de> References: <20240904104147.8c1e74632b2c6d4f6a759ee6@magnetkern.de> Subject: Re: Privileges using security tokens through PC/SC-daemon List-Id: Security issues List-Archive: https://lists.freebsd.org/archives/freebsd-security List-Help: List-Post: List-Subscribe: List-Unsubscribe: X-BeenThere: freebsd-security@freebsd.org Sender: owner-freebsd-security@FreeBSD.org MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit 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:210909, ipnet:185.205.69.0/24, country:DE] X-Rspamd-Queue-Id: 4WzRcj4m07z4RYj Hi Jan, I have never used Yubikeys on FreeBSD and can't offer a whole lot of insight. I installed security/yubikey-manager-qt. ykman doesn't appear to be setuid, which was my first thought. Since it's not setuid, is there a /dev device for the Yubikey has global read (and write?) access? I'm not aware if/how policykit is involved here. -Henrich Sep 4, 2024, 08:42 by jbe-mlist@magnetkern.de: > Hello, > > I'm using packages "pcsc-lite-2.2.2,2" and "polkit-124_3" and set > "pcscd_enable" to "YES" in "/etc/rc.conf". > > My computer has a YubiKey 5 NFC with firmware version 5.7.1 connected > to it. When I create an unprivileged user account and log in from a > remote machine (through ssh), then this unprivileged user account can > use "ykman" to access my security key and, for example, list stored > credentials, generate one-time tokens, erase or temporariliy block the > device (by providing a wrong PIN), or even effectively brick it (if no > configuration password is set). > > As far as I understand, polkit should prohibit this. pcsc-lite installs > a file "/usr/local/share/polkit-1/actions/org.debian.pcsc-lite.policy" > with the following contents: > > ------------ > > "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN" > "http://www.freedesktop.org/standards/PolicyKit/1.0/policyconfig.dtd"> > > The PCSC-lite Project > https://pcsclite.apdu.fr/ > > > > Access to the PC/SC daemon > Authentication is required to access the PC/SC daemon > > no > no > yes > > > > > Access to the smart card > Authentication is required to access the smart card > > no > no > yes > > > > > ------------ > > Changing "allow_active" from "yes" to "no" and restarting "pcscd" has > no impact either. > > I don't understand what is going on, but this behavior doesn't seem to > be correct. A non-privileged user (that isn't even member of group > "u2f") should not gain access to a security token plugged into the > machine. > > Is this behavior reproducible by others, or maybe just a configuration > mistake by me? > > I previously mentioned this issue here: > https://forums.FreeBSD.org/threads/94605/post-670209 > > Kind Regards, > Jan Behrens >