Date: Fri, 23 Dec 2011 13:42:25 -0500 From: Alexander Kabaev <kabaev@gmail.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Colin Percival <cperciva@freebsd.org>, John Baldwin <jhb@freebsd.org> Subject: Re: svn commit: r228843 - head/contrib/telnet/libtelnet head/crypto/heimdal/appl/telnet/libtelnet head/include head/lib/libc/gen head/lib/libc/iconv head/lib/libc/include head/lib/libc/net head/libexec... Message-ID: <20111223134225.11ac22fd@kan.dyndns.org> In-Reply-To: <20111223182959.GL50300@deviant.kiev.zoral.com.ua> References: <201112231500.pBNF0c0O071712@svn.freebsd.org> <201112231058.46642.jhb@freebsd.org> <201112231122.34436.jhb@freebsd.org> <20111223120644.75fe944d@kan.dyndns.org> <20111223175143.GJ50300@deviant.kiev.zoral.com.ua> <20111223132034.12192baa@kan.dyndns.org> <20111223182959.GL50300@deviant.kiev.zoral.com.ua>
next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/TYfRu/NI0Pads61ub84RGK+ Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Fri, 23 Dec 2011 20:29:59 +0200 Kostik Belousov <kostikbel@gmail.com> wrote: > On Fri, Dec 23, 2011 at 01:20:34PM -0500, Alexander Kabaev wrote: > > On Fri, 23 Dec 2011 19:51:43 +0200 > > Kostik Belousov <kostikbel@gmail.com> wrote: > >=20 > > > On Fri, Dec 23, 2011 at 12:06:44PM -0500, Alexander Kabaev wrote: > > > > On Fri, 23 Dec 2011 11:22:34 -0500 > > > > John Baldwin <jhb@freebsd.org> wrote: > > > >=20 > > > > > On Friday, December 23, 2011 10:58:46 am John Baldwin wrote: > > > > > > On Friday, December 23, 2011 10:00:38 am Colin Percival > > > > > > wrote: > > > > > > > Author: cperciva > > > > > > > Date: Fri Dec 23 15:00:37 2011 > > > > > > > New Revision: 228843 > > > > > > > URL: http://svn.freebsd.org/changeset/base/228843 > > > > > > >=20 > > > > > > > Log: > > > > > > > Fix a problem whereby a corrupt DNS record can cause > > > > > > > named to crash. [11:06]=20 > > > > > > > Add an API for alerting internal libc routines to the > > > > > > > presence of "unsafe" paths post-chroot, and use it in > > > > > > > ftpd. [11:07] > > > > > >=20 > > > > > > Eh, the whole libc_dlopen() thing looks like a gross hack > > > > > > (and who came up with that weird symbol name for a public > > > > > > API????). Is it really even needed given the other fix to > > > > > > have ftpd drop privilege before execing a helper program? > > > > > > I guess the main reason I don't like it is it doesn't do > > > > > > anything to address the more general problem. I would have > > > > > > expected instead something to restrict dlopen() entirely > > > > > > including from other libraries than just libc in certain > > > > > > circumstances. > > > > >=20 > > > > > At the very least if we feel that the libc_dlopen() thing is a > > > > > temporary band-aid, we should move the new symbols into the > > > > > private namespace so we can remove them once the better fix > > > > > is in rather than being required to support them forever. > > > libc_dlopen() is not exposed. > > > The __FreeBSD_libc_enter_restricted_mode() is, and its name is > > > ugly exactly to note the ugly intent. I do not see how the symbol > > > can go int FBSDprivate_1.0 when it was supposed to be used by > > > third-party applications. > > >=20 > > > Putting this hack into rtld itself IMO has to wide consequences. > > > For libc, we can enumerate the points that stop work after the > > > call, but for the generic applications the consequences are > > > undefined. > > > > >=20 > > > > > --=20 > > > > > John Baldwin > > > >=20 > > > > Pardon for not catching that when I had a chance to influence > > > > the outcome, but I would like to voice my support to tucking the > > > > ugliness into private version namespace. > > > >=20 > > > > --=20 > > > > Alexander Kabaev > > >=20 > > Putting symbol into official namespace implies that we are willing > > to provide and maintain it forever, which I do not think was the > > intent for the function in question. FBSD_PRIVATE says nothing > > about who should and should not link to it, only the level of API > > stability one has to expect in the end. If/when we have better > > security mechanisms (capsicum?) available to users by default, this > > should be ripped out with extreme prejudice. >=20 > The API is offered as a solution to third-parties. Telling them to use > the API that is known to be broken in future is wrong step for the > project, IMO. >=20 > I doubt that proftpd will 'go capsicum'. Then proftp will have to contend with being known security hazard. Spamming every supported branch with the symbol that cries just to support programs that chroot into arbitrary environments and trust anything at all there is wrong step for the project. Committing to support said symbol for all of the eternity is even bigger mistake. =20 --=20 Alexander Kabaev --Sig_/TYfRu/NI0Pads61ub84RGK+ Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.18 (FreeBSD) iD8DBQFO9MuhQ6z1jMm+XZYRArrcAJ9Vtx8Qnztq9oK0hDH41zttAk1V0ACffqnB erT9XbQjXygPsASPPWRihkM= =0Hoo -----END PGP SIGNATURE----- --Sig_/TYfRu/NI0Pads61ub84RGK+--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111223134225.11ac22fd>