From nobody Sat Dec 6 07:37:43 2025 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 4dNg8335nMz6KHMl for ; Sat, 06 Dec 2025 07:37:55 +0000 (UTC) (envelope-from Wismos@proton.me) Received: from mail-43167.protonmail.ch (mail-43167.protonmail.ch [185.70.43.167]) (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 RSA-PSS (4096 bits) client-digest SHA256) (Client CN "protonmail.com", Issuer "R13" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4dNg830bTRz3tlw for ; Sat, 06 Dec 2025 07:37:50 +0000 (UTC) (envelope-from Wismos@proton.me) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1765006667; x=1765265867; bh=zxd870DDcpK6rmpdZDkNFDm+Csvp56l+O3+9j0qRNDM=; h=Date:To:From:Cc:Subject:Message-ID:In-Reply-To:References: Feedback-ID:From:To:Cc:Date:Subject:Reply-To:Feedback-ID: Message-ID:BIMI-Selector; b=SR4P5OLN9U1u5KcfNuW2KsgbE2n06HiXgRXQc90Ve/w8KaTqu1WwMLb+2ohXVHoMy gJtMR+n0ZqYcJ6iHMb4dMRIwomVPCTtU/1yBTCVZxzSMBpg1+KE9rj3BtSt18J+wEP kh3qWVhFM1+dGcP9AbvRX3Krv6jORzg3Dp07FTulvaIUbWT4YAQLGvQUk0uLBXUfG1 8k9kY+bew9cVUhUr93T2mVpc9+fuc4z+sSs18nIMnjmItUFOkkZcEV4fNElmNsFqBT TSrQMiFCeTf9pxmhaaruoCDwPKS+Cykdbs4TfI0n94Y2Z6U81kNtQ0Wdn2rHXW1wR4 hAmSwWIxB/iVw== Date: Sat, 06 Dec 2025 07:37:43 +0000 To: Olivier Certner From: Wismos@proton.me Cc: freebsd-security@freebsd.org Subject: Re: Regarding PAM support for mdo Message-ID: In-Reply-To: <24612612.gYbqZ1YImA@ravel> References: <5yH9o0uW628frXojj_IKQVxRqtYT0Z9ZrqQp8eAbNXa3iuQoTT-Nm2zN_yNTc89dzFPvnrYkIIkL5yjmmFZ1z9FmaGpM7_sYJ0t1Ho2ktr0=@proton.me> <24612612.gYbqZ1YImA@ravel> Feedback-ID: 51325846:user:proton X-Pm-Message-ID: a530407270fb6db59d979a7d2f472c6881a24a6a 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: quoted-printable X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-Rspamd-Queue-Id: 4dNg830bTRz3tlw Thanks for the info > Hello, >=20 > > so i would be really glad to know if the reason were some blockers or s= ecurity wise issues i am not aware of >=20 > Yes, there was a reason: It doesn't fit in the current mac_do(4)/mdo(1) f= ramework in a straightforward manner. >=20 > mdo(1) is not a setuid executable (a feature), which basically means that= PAM, which expects to be root, is unlikely to function correctly. E.g., it= 's impossible on FreeBSD for a non-root user to validate some password agai= nst the database, as 'master.passwd' is only readable by 'root'. CAPSICUM p= rograms have the related problem of not having enough privileges for some o= perations, but their way out, libcasper(3), currently wouldn't solve our pr= oblem (still not enough privileges to access the password database) and cod= e would have to be written there for some PAM functions to be accessible th= rough it (it's mostly and perhaps only the authentication phase that could = interest us in PAM). >=20 > Using PAM also means starting to rely on the filesystem hierarchy, with i= mplications in terms of security when leveraging jails and chroots (confuse= d deputy issues, as described in August on hackers@). Currently, mdo(1) doe= s not read any configuration file at all, and thus is not subject to such p= roblems. They are however easy to avoid (by leveraging P2_NO_NEW_PRIVS; at = the price of functionality restrictions). >=20 > What is your goal exactly? Having a simple program like doas(1) replacing= sudo(8)? I'm evoking a number of possible mac_do(4)/mdo(1) evolutions in a= n article in the next FreeBSD Journal issue. One may be to have another exe= cutable, with the setuid mode bit set this time, that could leverage PAM wi= th full privileges, and drop them the rest of the time until calling setcre= d() (this code could be share with mdo(1)). Another is to have an ad-hoc au= thentication mechanism, but then we would still need a mechanism to safely = read a password database, e.g., communicate with a privileged server, which= still remains to be written. There are number of other solutions with diff= erent advantages/drawbacks. >=20 > The following steps are unclear, and mainly depend on user needs/feedback= s. >=20 > Thanks and regards. >=20 > -- > Olivier Certner my goal is to either have an authentication prompt setup for every time a p= rocess from a certain uid is trying to change credentials or to have a some= form of blacklist/whitelist to only allow certain processes to be able to = change credentials from the response it's clear that a password based authentication prompt is= not ideal for mdo currently but perhaps the whitelist/blacklist may work if we were able to figure out = how to make it know which process to escalate without introducing reliance = on filesytem hierarchy,perhaps MAC/veriexec might be suitable to verify the= executable file allowed to change credentials? looking forward to your thoughts and thanks again