From nobody Wed Jan 7 19:03:49 2026 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 4dmcrx0dYYz6NCL7 for ; Wed, 07 Jan 2026 19:04:01 +0000 (UTC) (envelope-from Wismos@proton.me) Received: from mail-4319.protonmail.ch (mail-4319.protonmail.ch [185.70.43.19]) (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 4dmcrs5RKDz3DrK for ; Wed, 07 Jan 2026 19:03:57 +0000 (UTC) (envelope-from Wismos@proton.me) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=proton.me header.s=protonmail header.b=NjZslLMs; dmarc=pass (policy=quarantine) header.from=proton.me; spf=pass (mx1.freebsd.org: domain of Wismos@proton.me designates 185.70.43.19 as permitted sender) smtp.mailfrom=Wismos@proton.me DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=proton.me; s=protonmail; t=1767812634; x=1768071834; bh=eg2QE6cvssogv5iW4JoDL6rFCsMzCEjZNQh/tHNjZ9E=; 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=NjZslLMs0EqdHHrPGn8t3xGnQcv8/33ZzpEPQriJ7rAq/1Fo2s4cbqJhNoRAjCRRR HsNNn2XqFXQ36AF3jTM10BRgDMwTxGHzRHw4H6nDcGk6NbDOcYL63BrQ2WRWarlBWn +9eVlDyqrBT++HtM8rD3i2GvUuKr/kqbjmE0VcHoDwUgYXvWgIjQyXJgcQJ/hHVq1H VlIeirpd3wV53xR+luo7diCUPXOygLEnSpdh3VGYFHyyN5Xw2ca2609pfVhqvWwTtq pQHhABz1LP/zHAHpH4zkKgfWcJC+UefYixiayFWga++6O6rHcH9qVCUAbG/i9xqtSh pGe2Kuoq7MaXQ== Date: Wed, 07 Jan 2026 19:03:49 +0000 To: Wismos@proton.me From: Wismos@proton.me Cc: Olivier Certner , freebsd-security@freebsd.org Subject: Re: Regarding PAM support for mdo Message-ID: In-Reply-To: References: <5yH9o0uW628frXojj_IKQVxRqtYT0Z9ZrqQp8eAbNXa3iuQoTT-Nm2zN_yNTc89dzFPvnrYkIIkL5yjmmFZ1z9FmaGpM7_sYJ0t1Ho2ktr0=@proton.me> <24612612.gYbqZ1YImA@ravel> Feedback-ID: 51325846:user:proton X-Pm-Message-ID: 3fe874b179c75ab5e892eb089d5de1881dc0151f 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.40 / 15.00]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-0.998]; DMARC_POLICY_ALLOW(-0.50)[proton.me,quarantine]; RWL_MAILSPIKE_EXCELLENT(-0.40)[185.70.43.19:from]; R_SPF_ALLOW(-0.20)[+ip4:185.70.43.0/24]; R_DKIM_ALLOW(-0.20)[proton.me:s=protonmail]; MIME_GOOD(-0.10)[text/plain]; FROM_NO_DN(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_IN_DNSWL_NONE(0.00)[185.70.43.19:from]; MISSING_XM_UA(0.00)[]; TO_DN_SOME(0.00)[]; ASN(0.00)[asn:62371, ipnet:185.70.43.0/24, country:CH]; RCVD_COUNT_ZERO(0.00)[0]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; ARC_NA(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; DKIM_TRACE(0.00)[proton.me:+] X-Rspamd-Queue-Id: 4dmcrs5RKDz3DrK Hi again olce, i was wondering about what are your thoughts on utilising mac_grantbylabel = and mac_veriexec for mdo as far as i am aware,there shouldn't be any confused deputy problem or any = reliance on anything FS related and shouldn't cause any functionality restr= iction i can give it a try if everything seems right to you >=20 >=20 > Thanks for the info >=20 > > Hello, > >=20 > > > so i would be really glad to know if the reason were some blockers or= security 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)= framework in a straightforward manner. > >=20 > > mdo(1) is not a setuid executable (a feature), which basically means th= at 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 ag= ainst the database, as 'master.passwd' is only readable by 'root'. CAPSICUM= programs have the related problem of not having enough privileges for some= operations, but their way out, libcasper(3), currently wouldn't solve our = problem (still not enough privileges to access the password database) and c= ode would have to be written there for some PAM functions to be accessible = through it (it's mostly and perhaps only the authentication phase that coul= d interest us in PAM). > >=20 > > Using PAM also means starting to rely on the filesystem hierarchy, with= implications in terms of security when leveraging jails and chroots (confu= sed deputy issues, as described in August on hackers@). Currently, mdo(1) d= oes not read any configuration file at all, and thus is not subject to such= problems. They are however easy to avoid (by leveraging P2_NO_NEW_PRIVS; a= t the price of functionality restrictions). > >=20 > > What is your goal exactly? Having a simple program like doas(1) replaci= ng sudo(8)? I'm evoking a number of possible mac_do(4)/mdo(1) evolutions in= an article in the next FreeBSD Journal issue. One may be to have another e= xecutable, with the setuid mode bit set this time, that could leverage PAM = with full privileges, and drop them the rest of the time until calling setc= red() (this code could be share with mdo(1)). Another is to have an ad-hoc = authentication mechanism, but then we would still need a mechanism to safel= y read a password database, e.g., communicate with a privileged server, whi= ch still remains to be written. There are number of other solutions with di= fferent advantages/drawbacks. > >=20 > > The following steps are unclear, and mainly depend on user needs/feedba= cks. > >=20 > > Thanks and regards. > >=20 > > -- > > Olivier Certner >=20 >=20 > my goal is to either have an authentication prompt setup for every time a= process from a certain uid is trying to change credentials or to have a so= me form of blacklist/whitelist to only allow certain processes to be able t= o change credentials >=20 > from the response it's clear that a password based authentication prompt = is not ideal for mdo currently >=20 > but perhaps the whitelist/blacklist may work if we were able to figure ou= t how to make it know which process to escalate without introducing relianc= e on filesytem hierarchy,perhaps MAC/veriexec might be suitable to verify t= he executable file allowed to change credentials? >=20 > looking forward to your thoughts and thanks again