Date: Tue, 09 Sep 2014 02:00:06 +0400 From: Andrey Chernov <ache@freebsd.org> To: Patrick Kelsey <kelsey@ieee.org> Cc: George Neville-Neil <gnn@freebsd.org>, current@freebsd.org Subject: Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient Message-ID: <540E26E6.5070700@freebsd.org> In-Reply-To: <CAD44qMW0k=o_YwU3Jus6TM1P2K2kzCKupDi6ZDDwjP5DogJpbw@mail.gmail.com> References: <CAD44qMWgWn_OZ1i0Jy2WTLY=YAai%2B6-_Bq24QN-AjD9iYJ2JOA@mail.gmail.com> <540E14C4.9080201@freebsd.org> <CAD44qMW0k=o_YwU3Jus6TM1P2K2kzCKupDi6ZDDwjP5DogJpbw@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 09.09.2014 1:13, Patrick Kelsey wrote: > You make a godo point about the wider use of fcntl() in libc - aside > from the rpc code, by my count there are 14 other entry points in libc > that use fcntl in their implementation. To experience breakage, > programs that use those entry points would also have to be supplying > them fds with restricted rights that do not include CAP_FCNTL. By my > count, there are currently only 12 programs in -current that call > cap_rights_limit(). I don't think these counts inform us very well as > to the presence and extent of any capsicum+libc issues similar to the > one that I've raised. Those 12 programs mentioned above would have to > be audited to determine if any of the 15 libc entry points (including > fcntl) that use fcntl are being used on those restricted fds without > being granted CAP_FCNTL rights, and whether there are overt or potential > failures occurring as a result. Consider that the failure mode in > tcpdump that I found requires that you be using multiple capture files > with size-based rotation, otherwise all works fine. Also consider that > the failure mode in dhclient only occurs when a rewritten client lease > file is smaller than its predecessor. Just to note by quick glance: tcpdump use fdopen(), so in some cases probably already broken without F_GETFL rights. openssh use fdopen(), so suspicious about F_GETFL too, but I don't traverse the order in which fdopen() and cap_rights_* there are applied. > I don't think that this read-only fcntl(F_GETFL) which doesn not modify > anything deserves any special rights at all (i.e. can be just enabled by > default in contrast to F_SETFL), but I am not capsicum expert. > > I don't think I am in a position to comment on the implications of > permanent F_GETFL rights either. I do think that the point about wider > use of fcntl(F_GETFL) in libc does argue against making a CAP_FSEEK > right in sys/capability.h, as it would appear users of capsicum and libc > are more in need of a map of capsicum rights required by libc entry > points than they are of convenience #defines. Theoretically it will be possible to get rid of fcntl(F_GETFL) in fseek(), but O_APPEND flag need to be stored somewhere in that case, and stdio _flags already have all bit occupied for 16bit short. So the price will be changing size of the main stdio structure __sFILE to add new space for flags, which is undesirable I think. -- http://ache.vniz.net/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?540E26E6.5070700>