From nobody Sat Dec 6 05:47:42 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 4dNcjL68Bjz6K8ps for ; Sat, 06 Dec 2025 05:48:06 +0000 (UTC) (envelope-from info@spmzt.net) Received: from mail.spmzt.net (mail.spmzt.net [193.148.248.214]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4dNcjK2H49z3gMK; Sat, 06 Dec 2025 05:48:05 +0000 (UTC) (envelope-from info@spmzt.net) Authentication-Results: mx1.freebsd.org; dkim=pass header.d=spmzt.net header.s=mail header.b=d+lNEvLf; dmarc=pass (policy=quarantine) header.from=spmzt.net; spf=pass (mx1.freebsd.org: domain of info@spmzt.net designates 193.148.248.214 as permitted sender) smtp.mailfrom=info@spmzt.net DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=spmzt.net; s=mail; t=1765000076; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=woUjuW8ms8Tq6d2mpknnEtIXVZCaQ+WaSKBJw+U40CE=; b=d+lNEvLf+Kd2sqLxXY2yDxVzYrig/uqn1MM4lxGxdjVOJFZhjAoptacyluCvPj4fEJKCMZ MCJHGTgS04p+7eNH1IzB9r1AIyLuNl+NnG0EwBRabO0dIYduFbVAM5U89Ms2/3o+QKQpxv M8Cx61LYt251DSEWus9zyKg1/sLrxxc= Received: by nl.mail.spmzt.net (OpenSMTPD) with ESMTPSA id 0893684a (TLSv1.3:TLS_AES_256_GCM_SHA384:256:NO); Sat, 6 Dec 2025 09:17:55 +0330 (+0330) Message-ID: Date: Sat, 6 Dec 2025 09:17:42 +0330 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 User-Agent: Mozilla Thunderbird Subject: Re: Regarding PAM support for mdo Content-Language: en-US, fa-IR References: <912767d4-9cf1-43b1-b6e9-66fed003d8e9@spmzt.net> To: Wismos@proton.me Cc: freebsd-security@freebsd.org, olce@freebsd.org From: Seyed Pouria Mousavizadeh Tehrani Organization: SPMZT - AS214145 In-Reply-To: <912767d4-9cf1-43b1-b6e9-66fed003d8e9@spmzt.net> X-Forwarded-Message-Id: <912767d4-9cf1-43b1-b6e9-66fed003d8e9@spmzt.net> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------vHXrw9MIoe0h5RL0LvnbnAPv" X-Spamd-Bar: ----- X-Spamd-Result: default: False [-6.00 / 15.00]; SIGNED_PGP(-2.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[spmzt.net,quarantine]; MIME_GOOD(-0.20)[multipart/signed,multipart/mixed,multipart/alternative,text/plain]; R_DKIM_ALLOW(-0.20)[spmzt.net:s=mail]; R_SPF_ALLOW(-0.20)[+mx]; MIME_BASE64_TEXT(0.10)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:+,4:~,5:~]; ASN(0.00)[asn:34927, ipnet:193.148.248.0/24, country:CH]; RCVD_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; FROM_EQ_ENVFROM(0.00)[]; FROM_HAS_DN(0.00)[]; DKIM_TRACE(0.00)[spmzt.net:+]; TO_DN_NONE(0.00)[]; MLMMJ_DEST(0.00)[freebsd-security@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; HAS_ATTACHMENT(0.00)[] X-Rspamd-Queue-Id: 4dNcjK2H49z3gMK This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------vHXrw9MIoe0h5RL0LvnbnAPv Content-Type: multipart/mixed; boundary="------------jaiAeZP22d48I4SY27laD95H"; protected-headers="v1" Message-ID: Date: Sat, 6 Dec 2025 09:17:42 +0330 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: Regarding PAM support for mdo Content-Language: en-US, fa-IR References: <912767d4-9cf1-43b1-b6e9-66fed003d8e9@spmzt.net> To: Wismos@proton.me Cc: freebsd-security@freebsd.org, olce@freebsd.org From: Seyed Pouria Mousavizadeh Tehrani Organization: SPMZT - AS214145 In-Reply-To: <912767d4-9cf1-43b1-b6e9-66fed003d8e9@spmzt.net> X-Forwarded-Message-Id: <912767d4-9cf1-43b1-b6e9-66fed003d8e9@spmzt.net> --------------jaiAeZP22d48I4SY27laD95H Content-Type: multipart/alternative; boundary="------------NCzZKF0BhYUmTb0Ox0GipUes" --------------NCzZKF0BhYUmTb0Ox0GipUes Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: base64 SGksDQoNCj4+IHNvIGkgd291bGQgYmUgcmVhbGx5IGdsYWQgdG8ga25vdyBpZiB0aGUgcmVh c29uIHdlcmUgc29tZSBibG9ja2VycyBvciBzZWN1cml0eSB3aXNlIGlzc3VlcyBpIGFtIG5v dCBhd2FyZSBvZg0KPiBZZXMsIHRoZXJlIHdhcyBhIHJlYXNvbjogSXQgZG9lc24ndCBmaXQg aW4gdGhlIGN1cnJlbnQgbWFjX2RvKDQpL21kbygxKSBmcmFtZXdvcmsgaW4gYSBzdHJhaWdo dGZvcndhcmQgbWFubmVyLg0KPg0KPiBtZG8oMSkgaXMgbm90IGEgc2V0dWlkIGV4ZWN1dGFi bGUgKGEgZmVhdHVyZSksIHdoaWNoIGJhc2ljYWxseSBtZWFucyB0aGF0IFBBTSwgd2hpY2gg ZXhwZWN0cyB0byBiZSByb290LCBpcyB1bmxpa2VseSB0byBmdW5jdGlvbiBjb3JyZWN0bHku ICBFLmcuLCBpdCdzIGltcG9zc2libGUgb24gRnJlZUJTRCBmb3IgYSBub24tcm9vdCB1c2Vy IHRvIHZhbGlkYXRlIHNvbWUgcGFzc3dvcmQgYWdhaW5zdCB0aGUgZGF0YWJhc2UsIGFzICdt YXN0ZXIucGFzc3dkJyBpcyBvbmx5IHJlYWRhYmxlIGJ5ICdyb290Jy4gIENBUFNJQ1VNIHBy b2dyYW1zIGhhdmUgdGhlIHJlbGF0ZWQgcHJvYmxlbSBvZiBub3QgaGF2aW5nIGVub3VnaCBw cml2aWxlZ2VzIGZvciBzb21lIG9wZXJhdGlvbnMsIGJ1dCB0aGVpciB3YXkgb3V0LCBsaWJj YXNwZXIoMyksIGN1cnJlbnRseSB3b3VsZG4ndCBzb2x2ZSBvdXIgcHJvYmxlbSAoc3RpbGwg bm90IGVub3VnaCBwcml2aWxlZ2VzIHRvIGFjY2VzcyB0aGUgcGFzc3dvcmQgZGF0YWJhc2Up IGFuZCBjb2RlIHdvdWxkIGhhdmUgdG8gYmUgd3JpdHRlbiB0aGVyZSBmb3Igc29tZSBQQU0g ZnVuY3Rpb25zIHRvIGJlIGFjY2Vzc2libGUgdGhyb3VnaCBpdCAoaXQncyBtb3N0bHkgYW5k IHBlcmhhcHMgb25seSB0aGUgYXV0aGVudGljYXRpb24gcGhhc2UgdGhhdCBjb3VsZCBpbnRl cmVzdCB1cyBpbiBQQU0pLg0KPg0KPiBVc2luZyBQQU0gYWxzbyBtZWFucyBzdGFydGluZyB0 byByZWx5IG9uIHRoZSBmaWxlc3lzdGVtIGhpZXJhcmNoeSwgd2l0aCBpbXBsaWNhdGlvbnMg aW4gdGVybXMgb2Ygc2VjdXJpdHkgd2hlbiBsZXZlcmFnaW5nIGphaWxzIGFuZCBjaHJvb3Rz IChjb25mdXNlZCBkZXB1dHkgaXNzdWVzLCBhcyBkZXNjcmliZWQgaW4gQXVndXN0IG9uIGhh Y2tlcnNAKS4gIEN1cnJlbnRseSwgbWRvKDEpIGRvZXMgbm90IHJlYWQgYW55IGNvbmZpZ3Vy YXRpb24gZmlsZSBhdCBhbGwsIGFuZCB0aHVzIGlzIG5vdCBzdWJqZWN0IHRvIHN1Y2ggcHJv YmxlbXMuICBUaGV5IGFyZSBob3dldmVyIGVhc3kgdG8gYXZvaWQgKGJ5IGxldmVyYWdpbmcg UDJfTk9fTkVXX1BSSVZTOyBhdCB0aGUgcHJpY2Ugb2YgZnVuY3Rpb25hbGl0eSByZXN0cmlj dGlvbnMpLg0KPg0KPiBXaGF0IGlzIHlvdXIgZ29hbCBleGFjdGx5PyAgSGF2aW5nIGEgc2lt cGxlIHByb2dyYW0gbGlrZSBkb2FzKDEpIHJlcGxhY2luZyBzdWRvKDgpPyAgSSdtIGV2b2tp bmcgYSBudW1iZXIgb2YgcG9zc2libGUgbWFjX2RvKDQpL21kbygxKSBldm9sdXRpb25zIGlu IGFuIGFydGljbGUgaW4gdGhlIG5leHQgRnJlZUJTRCBKb3VybmFsIGlzc3VlLiAgT25lIG1h eSBiZSB0byBoYXZlIGFub3RoZXIgZXhlY3V0YWJsZSwgd2l0aCB0aGUgc2V0dWlkIG1vZGUg Yml0IHNldCB0aGlzIHRpbWUsIHRoYXQgY291bGQgbGV2ZXJhZ2UgUEFNIHdpdGggZnVsbCBw cml2aWxlZ2VzLCBhbmQgZHJvcCB0aGVtIHRoZSByZXN0IG9mIHRoZSB0aW1lIHVudGlsIGNh bGxpbmcgc2V0Y3JlZCgpICh0aGlzIGNvZGUgY291bGQgYmUgc2hhcmUgd2l0aCBtZG8oMSkp LiAgQW5vdGhlciBpcyB0byBoYXZlIGFuIGFkLWhvYyBhdXRoZW50aWNhdGlvbiBtZWNoYW5p c20sIGJ1dCB0aGVuIHdlIHdvdWxkIHN0aWxsIG5lZWQgYSBtZWNoYW5pc20gdG8gc2FmZWx5 IHJlYWQgYSBwYXNzd29yZCBkYXRhYmFzZSwgZS5nLiwgY29tbXVuaWNhdGUgd2l0aCBhIHBy aXZpbGVnZWQgc2VydmVyLCB3aGljaCBzdGlsbCByZW1haW5zIHRvIGJlIHdyaXR0ZW4uICBU aGVyZSBhcmUgbnVtYmVyIG9mIG90aGVyIHNvbHV0aW9ucyB3aXRoIGRpZmZlcmVudCBhZHZh bnRhZ2VzL2RyYXdiYWNrcy4NCj4NCj4gVGhlIGZvbGxvd2luZyBzdGVwcyBhcmUgdW5jbGVh ciwgYW5kIG1haW5seSBkZXBlbmQgb24gdXNlciBuZWVkcy9mZWVkYmFja3MuDQpBcyBhIHVz ZXIgb2YgbWFjX2RvKDQpL21kbygxKSwgSSBzdHJvbmdseSBiZWxpZXZlIHRoZSBjdXJyZW50 IA0KaW1wbGVtZW50YXRpb24gb2YgbWFjX2RvKDQpIGlzIHBlcmZlY3QuIElNSE8gYW5kIG9u bHkgSU1ITywgYW55IGNoYW5nZSANCnRvIG1hY19kbyBzaG91bGQgTk9UIGJyZWFrIHRoZXNl IGV4cGVjdGF0aW9ucyBiZWxvdyB0byBtYWNfZG8oNCksIHdoaWNoIA0KYXJlIHRoZSByZWFz b25zIHdlIHVzZSBpdDoNCg0KICAqIE5vIGRlcGVuZGVuY3kgb24gYSBjb25maWd1cmF0aW9u IGZpbGUgKHN5c2N0bC1iYXNlZCkNCiAgKiBObyBmaWxlc3lzdGVtIGRlcGVuZGVuY2llcyAo aW5jbHVkaW5nIHRoZSBzZXR1aWQgYml0KQ0KICAqIEphaWwgaW5oZXJpdGFuY2Ugc3VwcG9y dA0KICAqIFN0cmFpZ2h0Zm9yd2FyZMKgdWNyZWQtc3BlY2lmaWPCoHN5bnRheA0KDQpDb21t dW5pdHkgYXBwcmVjaWF0ZSBpbXByb3ZlbWVudHMgdG8gbWFjX2RvOyBob3dldmVyLCBhbnkg Y2hhbmdlIHRoYXQgDQphZmZlY3RzIHRoZSBhYm92ZSByZWFzb25zIHdpbGwgZGVmZWF0IG1h Y19kb+KAmXMgbWFpbiBwdXJwb3NlIGFuZCB0dXJuIGl0IA0KaW50byBrZXJuZWwtdG8tc3lz dGVtIGdsdWUsIG1ha2luZyBpdCBvZiBsaXR0bGUgdG8gbm8gdmFsdWUgdG8gaXRzIHVzZXJz IA0KY29tcGFyZWQgd2l0aCBkb2FzKDEpLg0KDQpJIGhhdmUgYSBmZXcgc3VnZ2VzdGlvbnM6 DQoNCiAgKiBBbnkgYWRkaXRpb24gb3IgaW1wcm92ZW1lbnQgbm90IHJlbGF0ZWQgdG8gdWNy ZWQgc2hvdWxkIGJlIGluDQogICAgYW5vdGhlciBzeXNjdGwgbm9kZSB0byBub3QgYnJlYWsg Y29tcGF0aWJpbGl0eS4NCiAgKiBJIGZvdW5kIHRoYXQgbGVhcm5pbmcgY3VycmVudCBtYWNf ZG8oNCkgYWZ0ZXIgcmVhZGluZyBpdHMgbWFudWFsDQogICAgcmVxdWlyZXMgdHJ5LWFuZC1l cnJvciB0byB1bmRlcnN0YW5kIGl0cyBmdW5jdGlvbi4gTmV3IHVzZXJzIGZpcnN0DQogICAg aGF2ZSB0byB1bmxlYXJuIHRoaW5ncyBhYm91dCBkb2FzKDEpL3N1ZG8oOCkgYW5kIHVuZGVy c3RhbmQgdGhhdA0KICAgIG1hY19kbyBpcyBzdHJvbmdseSBleHBsaWNpdCBpbiBpdHMgY3Jl ZGVudGlhbHMuIHdoaWNoIGlzDQogICAgZ29vZC7CoFRoZXJlZm9yZSwgaXQgbXVzdCBiZSBo ZWF2aWx5IGRvY3VtZW50ZWQgY29uc2lkZXJpbmcgaXQgaGFzIGENCiAgICBzZWN1cml0eSBl ZmZlY3RzIHRvby4NCg0KSSBiZWxpZXZlIHRoZSBSRkMxOTI1IHN0YXRlbWVudCBhYm91dCBw cm90b2NvbCBkZXNpZ24gaXMgYWxzbyBhcHBsaWVzIHRvIA0Ka2VybmVsIG1vZHVsZXMuDQoN Ci8oMTIpIEluIHByb3RvY29sIGRlc2lnbiwgcGVyZmVjdGlvbiBoYXMgYmVlbiByZWFjaGVk IG5vdCB3aGVuIHRoZXJlIGlzIA0Kbm90aGluZyBsZWZ0IHRvIGFkZCwgYnV0ICp3aGVuIHRo ZXJlIGlzIG5vdGhpbmcgbGVmdCB0byB0YWtlwqBhd2F5Ki4vDQoNClRoYW5rIHlvdSBmb3Ig d29ya2luZyBvbiBtYWNfZG8uDQoNCi0tIA0Kc3BtenQNCg0K --------------NCzZKF0BhYUmTb0Ox0GipUes Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Hi,

so i would be really gla=
d to know if the reason were some blockers or security wise issues i am n=
ot aware of

Yes, there was a reason: I=
t doesn't fit in the current mac_do(4)/mdo(1) framework in a straightforw=
ard manner.

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=
 against the database, as 'master.passwd' is only readable by 'root'.  CA=
PSICUM 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 dat=
abase) and code 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 could interest us in PAM).

Using PAM also means starting to rely on the filesystem hierarchy, with i=
mplications in terms of security when leveraging jails and chroots (confu=
sed deputy issues, as described in August on hackers@).  Currently, mdo(1=
) does 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; at the price of functionality restrictions).

What is your goal exactly?  Having a simple program like doas(1) replacin=
g 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 anot=
her executable, with the setuid mode bit set this time, that could levera=
ge PAM with full privileges, and drop them the rest of the time until cal=
ling setcred() (this code could be share with mdo(1)).  Another is to hav=
e an ad-hoc authentication mechanism, but then we would still need a mech=
anism to safely read a password database, e.g., communicate with a privil=
eged server, which still remains to be written.  There are number of othe=
r solutions with different advantages/drawbacks.

The following steps are unclear, and mainly depend on user needs/feedback=
s.
As a user of mac_do(4)/mdo(1), I strongly believe the current implementation of mac_do(4) is perfect. IMHO and only IMHO, any change to mac_do should NOT break these expectations below to mac_do(4), which are the reasons we use it:
  • No dependency on a configuration file (sysctl-based)
  • No filesystem dependencies (including the setuid bit)
  • Jail inheritance support
  • Straightforward=C2=A0ucred-specific=C2=A0syntax
Community appreciate improvements to mac_do; however, any change that affects the above reasons will defeat mac_do=E2=80=99s main pu= rpose and turn it into kernel-to-system glue, making it of little to no value to its users compared with doas(1).

I have a few suggestions:

  • Any addition or improvement not related to ucred should be in another sysctl node to not break compatibility.
  • I found that learning current mac_do(4) after reading its manual requires try-and-error to understand its function. New users first have to unlearn things about doas(1)/sudo(8) and understand that mac_do is strongly explicit in its credentials. which is good.=C2=A0Therefore, it must be heavily documented considering it has a security effects too.

I believe the RFC1925 statement about protocol design is also applies to kernel modules.

(12) In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take=C2=A0away.

Thank you for working on mac_do. 
--=20
spmzt
--------------NCzZKF0BhYUmTb0Ox0GipUes-- --------------jaiAeZP22d48I4SY27laD95H-- --------------vHXrw9MIoe0h5RL0LvnbnAPv Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature.asc" -----BEGIN PGP SIGNATURE----- iHUEARYKAB0WIQSqt7cppfvJ816gj0lUwVnUeMwagAUCaTPDfgAKCRBUwVnUeMwa gNJKAQDlvRX8cP95mKaYEPBv78n6PNNEnlW30/MAZAe3hgz5PwD/VSQMrX2EX6Ja YViW7YHAbavGRGdiwomvwn6vowxyBgs= =r5TJ -----END PGP SIGNATURE----- --------------vHXrw9MIoe0h5RL0LvnbnAPv--