Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient

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/