Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Tuesday, September 16, 2014 12:42:36 PM Mateusz Guzik wrote: > On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote: > > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: > > > On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: > > > > On 09.09.2014 21:53, Patrick Kelsey wrote: > > > > > I don't think it is worth the trouble, as given the larger pattern > > > > > of > > > > > libc routines requiring multiple capsicum rights, it seems one will > > > > > in > > > > > general have to have libc implementation knowledge when using it in > > > > > concert with capsicum. For example, consider the limitfd() routine > > > > > in > > > > > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > > > > > stdout so the eventual call to isatty() via printf() will work as > > > > > > > > intended. > > > > > > > > > I think the above kdump example is a good one for the subtle issues > > > > > that > > > > > can arise when using capsicum with libc. That call to isatty() is > > > > > via a > > > > > widely-used internal libc routine __smakebuf(). __smakebuf() also > > > > > calls > > > > > __swhatbuf(), which in turn calls _fstat(), all to make sure that > > > > > output > > > > > to a tty is line buffered by default. It would appear that programs > > > > > that restrict rights on stdout without allowing CAP_IOCTL and > > > > > CAP_FSTAT > > > > > could be disabling the normally default line buffering when stdout > > > > > is a > > > > > tty. kdump goes the distance, but dhclient does not (restricting > > > > > stdout > > > > > to CAP_WRITE only). > > > > > > > > > > In any event, the patch attached to my first message is seeming like > > > > > the > > > > > way to go. > > > > > > > > Well, then commit it (if capsicum team agrees). > > > > > > Will do - thanks for the feedback. > > > > > > -Patrick > > > > Is there any possibility that this is related to the problem we've > > recently > > hit in the freebsd.org cluster with this month's refresh? > > > > After running for a while: > > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator > > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator > > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > > > > Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully > > last time (65258) > > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator > > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator > > Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > > > > Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully > > last time (28213) > > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator > > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator > > Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch > > returned > > error -1, errno is Capabilities insufficient > > > > I believe this jail was started from the boot process. If I restart the > > jail by hand from a ssh session the problem goes away. > > > > This is unbound from ports and I don't have any more details than this. > > This is new this month. > > Is this thingy multithreaded? > > Currently there is a race in the kernel where fd is visible before > relevant capabilities are installed. This can result in an error like > this one for weird processes. > > I got a patch for this: > http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.html > > but it got stalled on 'memory barrier' discussion. I'll try to ping > people to move it forward. > > IIRC there was a report of unbound failing this way, apparently fixed > with aforementioned patch. Yes, unbound is multi-threaded and your comment is the first potential explanation that makes sense so far. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Fri, Sep 12, 2014 at 09:29:56PM -0700, Peter Wemm wrote: > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: > > On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: > > > On 09.09.2014 21:53, Patrick Kelsey wrote: > > > > I don't think it is worth the trouble, as given the larger pattern of > > > > libc routines requiring multiple capsicum rights, it seems one will in > > > > general have to have libc implementation knowledge when using it in > > > > concert with capsicum. For example, consider the limitfd() routine in > > > > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > > > > stdout so the eventual call to isatty() via printf() will work as > > > > > > intended. > > > > > > > I think the above kdump example is a good one for the subtle issues that > > > > can arise when using capsicum with libc. That call to isatty() is via a > > > > widely-used internal libc routine __smakebuf(). __smakebuf() also calls > > > > __swhatbuf(), which in turn calls _fstat(), all to make sure that output > > > > to a tty is line buffered by default. It would appear that programs > > > > that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT > > > > could be disabling the normally default line buffering when stdout is a > > > > tty. kdump goes the distance, but dhclient does not (restricting stdout > > > > to CAP_WRITE only). > > > > > > > > In any event, the patch attached to my first message is seeming like the > > > > way to go. > > > > > > Well, then commit it (if capsicum team agrees). > > > > Will do - thanks for the feedback. > > > > -Patrick > > Is there any possibility that this is related to the problem we've recently > hit in the freebsd.org cluster with this month's refresh? > > After running for a while: > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully last > time (65258) > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator > Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator > Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully last > time (28213) > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator > Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator > Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient > > I believe this jail was started from the boot process. If I restart the jail > by hand from a ssh session the problem goes away. > > This is unbound from ports and I don't have any more details than this. This > is new this month. > Is this thingy multithreaded? Currently there is a race in the kernel where fd is visible before relevant capabilities are installed. This can result in an error like this one for weird processes. I got a patch for this: http://lists.freebsd.org/pipermail/freebsd-arch/2014-August/015788.html but it got stalled on 'memory barrier' discussion. I'll try to ping people to move it forward. IIRC there was a report of unbound failing this way, apparently fixed with aforementioned patch. -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On 13.09.2014 8:29, Peter Wemm wrote: > On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: >> On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: >>> On 09.09.2014 21:53, Patrick Kelsey wrote: I don't think it is worth the trouble, as given the larger pattern of libc routines requiring multiple capsicum rights, it seems one will in general have to have libc implementation knowledge when using it in concert with capsicum. For example, consider the limitfd() routine in kdump.c, which provides rights for the TIOCGETA ioctl to be used on stdout so the eventual call to isatty() via printf() will work as >>> >>> intended. >>> I think the above kdump example is a good one for the subtle issues that can arise when using capsicum with libc. That call to isatty() is via a widely-used internal libc routine __smakebuf(). __smakebuf() also calls __swhatbuf(), which in turn calls _fstat(), all to make sure that output to a tty is line buffered by default. It would appear that programs that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT could be disabling the normally default line buffering when stdout is a tty. kdump goes the distance, but dhclient does not (restricting stdout to CAP_WRITE only). In any event, the patch attached to my first message is seeming like the way to go. >>> >>> Well, then commit it (if capsicum team agrees). >> >> Will do - thanks for the feedback. >> >> -Patrick > > Is there any possibility that this is related to the problem we've recently > hit in the freebsd.org cluster with this month's refresh? > > After running for a while: > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator > Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator > Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned > error -1, errno is Capabilities insufficient unbound itself does not use capsicum, just grep cap_, ldns too, so the problem can be somewhere else. -- http://ache.vniz.net/ signature.asc Description: OpenPGP digital signature
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Thursday, September 11, 2014 12:38:02 PM Patrick Kelsey wrote: > On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: > > On 09.09.2014 21:53, Patrick Kelsey wrote: > > > I don't think it is worth the trouble, as given the larger pattern of > > > libc routines requiring multiple capsicum rights, it seems one will in > > > general have to have libc implementation knowledge when using it in > > > concert with capsicum. For example, consider the limitfd() routine in > > > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > > > stdout so the eventual call to isatty() via printf() will work as > > > > intended. > > > > > I think the above kdump example is a good one for the subtle issues that > > > can arise when using capsicum with libc. That call to isatty() is via a > > > widely-used internal libc routine __smakebuf(). __smakebuf() also calls > > > __swhatbuf(), which in turn calls _fstat(), all to make sure that output > > > to a tty is line buffered by default. It would appear that programs > > > that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT > > > could be disabling the normally default line buffering when stdout is a > > > tty. kdump goes the distance, but dhclient does not (restricting stdout > > > to CAP_WRITE only). > > > > > > In any event, the patch attached to my first message is seeming like the > > > way to go. > > > > Well, then commit it (if capsicum team agrees). > > Will do - thanks for the feedback. > > -Patrick Is there any possibility that this is related to the problem we've recently hit in the freebsd.org cluster with this month's refresh? After running for a while: Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 0: validator Sep 10 02:39:44 ns2 unbound: [65258:0] notice: init module 1: iterator Sep 10 11:44:29 ns2 unbound: [65258:3] fatal error: event_dispatch returned error -1, errno is Capabilities insufficient Sep 10 16:21:16 ns2 unbound: [28212:0] warning: did not exit gracefully last time (65258) Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 0: validator Sep 10 16:21:16 ns2 unbound: [28213:0] notice: init module 1: iterator Sep 11 10:23:49 ns2 unbound: [28213:5] fatal error: event_dispatch returned error -1, errno is Capabilities insufficient Sep 11 13:48:46 ns2 unbound: [79419:0] warning: did not exit gracefully last time (28213) Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 0: validator Sep 11 13:48:46 ns2 unbound: [79420:0] notice: init module 1: iterator Sep 11 18:42:56 ns2 unbound: [79420:6] fatal error: event_dispatch returned error -1, errno is Capabilities insufficient I believe this jail was started from the boot process. If I restart the jail by hand from a ssh session the problem goes away. This is unbound from ports and I don't have any more details than this. This is new this month. -- Peter Wemm - pe...@wemm.org; pe...@freebsd.org; pe...@yahoo-inc.com; KI6FJV UTF-8: for when a ' or ... just won\342\200\231t do\342\200\246 signature.asc Description: This is a digitally signed message part.
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Wed, Sep 10, 2014 at 3:00 AM, Andrey Chernov wrote: > On 09.09.2014 21:53, Patrick Kelsey wrote: > > I don't think it is worth the trouble, as given the larger pattern of > > libc routines requiring multiple capsicum rights, it seems one will in > > general have to have libc implementation knowledge when using it in > > concert with capsicum. For example, consider the limitfd() routine in > > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > > stdout so the eventual call to isatty() via printf() will work as > intended. > > > > I think the above kdump example is a good one for the subtle issues that > > can arise when using capsicum with libc. That call to isatty() is via a > > widely-used internal libc routine __smakebuf(). __smakebuf() also calls > > __swhatbuf(), which in turn calls _fstat(), all to make sure that output > > to a tty is line buffered by default. It would appear that programs > > that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT > > could be disabling the normally default line buffering when stdout is a > > tty. kdump goes the distance, but dhclient does not (restricting stdout > > to CAP_WRITE only). > > > > In any event, the patch attached to my first message is seeming like the > > way to go. > > Well, then commit it (if capsicum team agrees). > > > Will do - thanks for the feedback. -Patrick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On 09.09.2014 21:53, Patrick Kelsey wrote: > I don't think it is worth the trouble, as given the larger pattern of > libc routines requiring multiple capsicum rights, it seems one will in > general have to have libc implementation knowledge when using it in > concert with capsicum. For example, consider the limitfd() routine in > kdump.c, which provides rights for the TIOCGETA ioctl to be used on > stdout so the eventual call to isatty() via printf() will work as intended. > > I think the above kdump example is a good one for the subtle issues that > can arise when using capsicum with libc. That call to isatty() is via a > widely-used internal libc routine __smakebuf(). __smakebuf() also calls > __swhatbuf(), which in turn calls _fstat(), all to make sure that output > to a tty is line buffered by default. It would appear that programs > that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT > could be disabling the normally default line buffering when stdout is a > tty. kdump goes the distance, but dhclient does not (restricting stdout > to CAP_WRITE only). > > In any event, the patch attached to my first message is seeming like the > way to go. Well, then commit it (if capsicum team agrees). -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Mon, Sep 8, 2014 at 6:00 PM, Andrey Chernov wrote: > 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 have now looked at all of the programs in -current that call cap_rights_limit() (dhclient, hastd, ping, tcpdump, rwhod, ctld, iscsid, kdump, rwho, units, uniq, and sshd) and examined them to see which file descriptors cap_rights_limit() is invoked on, with what rights, and whether libc functions that require fcntl rights (fcntl, fdopendir, fdopen, freopen, fseek, ftell, popen, lockf, etc) are subsequently used on those descriptors. In most cases, the programs are simple and/or the application of cap_rights_limit() is otherwise limited in scope, and it is easy to see that they have sufficient rights on the restricted fds for the operations performed on those fds. This was a mostly manual inspection, and of course I may have missed something, but I did not find any further issues related to insufficient capsicum rights when using libc. In the case of tcpdump, fdopen() is not used on a file descriptor whose rights have been restricted via cap_rights_limit(). In the case of openssh, cap_rights_limit() is used by sshd to sandbox the unprivileged child process when using privilege separation by restricting the child's stdin, stdout, and stderr, the child's end of the socketpair used to communicate with the privileged parent and the child's end of the pipe used to log to the privileged parent. fdopen() is not used on any of those descriptors. > > 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. > > I don't think it is worth the trouble, as given the larger pattern of libc routines requiring multiple capsicum rights, it seems one will in general have to have libc implementation knowledge when using it in concert with capsicum. For example, consider the limitfd() routine in kdump.c, which provides rights for the TIOCGETA ioctl to be used on stdout so the eventual call to isatty() via printf() will work as intended. I think the above kdump example is a good one for the subtle issues that can arise when using capsicum with libc. That call to isatty() is via a widely-used internal libc routine __smakebuf(). __smakebuf() also calls __swhatbuf(), which in turn calls _fstat(), all to make sure that output to a tty is line buffered by default. It would appear that programs that restrict rights on stdout without allowing CAP_IOCTL and CAP_FSTAT could be disabling the normally default line buffering when stdout is a tty. kdump goes the distance, but dhclient does not (restricting stdout to CAP_WRITE only). In any event,
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/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On Mon, Sep 8, 2014 at 4:42 PM, Andrey Chernov wrote: > On 09.09.2014 0:28, Patrick Kelsey wrote: > > In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the > > non-append, write-only path. Consequently, programs that use _ftello() > > (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append, > > write-only files and that use capsicum to restrict capabilities on the > > associated fds to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and > > friends) calls on those files fail with ENOTCAPABLE due to lack of > > CAP_FCNTL rights. There appear to be only two affected programs in the > > tree - tcpdump and dhclient. This affects both CURRENT and 10-STABLE > > (including 10.1-PRERELEASE) > > > > tcpdump, when configured to write to capture files rotated by size, > > fails to rotate and captures indefinitely to the first file in the > > series. This can be reproduced by a command such as: tcpdump -i > > -C 1 -W 2 -w packets -v > > > > By inspection, dhclient will fail to trim old data from its client > > leases file when rewriting that file with a lesser amount of data than > > it currently contains. See the ftruncate() call in > > dhclient.c:rewrite_client_leases(). > > > > The attached patch adds CAP_FCNTL to the limited rights established for > > non-append, write-only files used by tcpdump and dhclient. It also > > restricts the fcntl rights to CAP_FCNTL_GETFL. > > > > The current need to have CAP_FCNTL rights in order to get or set the > > file position on non-append, write-only files is subtle. Perhaps part > > of the answer is to define a CAP_FSEEK right in sys/capability.h that > > resolves to CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in > > rights(4) to note the need for CAP_FCNTL when using ftell() and friends. > > > > -Patrick > > Stdio code use fcntl(F_GETFL) already in many places, f.e. fdopen(), > freopen(). libc code in general use it in rpc code. According to your > note, all that places are currently broken in anyway. > 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. > > 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. -Patrick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: _ftello() modification requires additional capsicum rights, breaking tcpdump and dhclient
On 09.09.2014 0:28, Patrick Kelsey wrote: > In r268997, _ftello() was modified to use _fcntl(F_GETFL) in the > non-append, write-only path. Consequently, programs that use _ftello() > (via ftell, fgetpos, fsetpos, fseek, rewind...) on non-append, > write-only files and that use capsicum to restrict capabilities on the > associated fds to [CAP_SEEK, CAP_WRITE] broke as all ftell() (and > friends) calls on those files fail with ENOTCAPABLE due to lack of > CAP_FCNTL rights. There appear to be only two affected programs in the > tree - tcpdump and dhclient. This affects both CURRENT and 10-STABLE > (including 10.1-PRERELEASE) > > tcpdump, when configured to write to capture files rotated by size, > fails to rotate and captures indefinitely to the first file in the > series. This can be reproduced by a command such as: tcpdump -i > -C 1 -W 2 -w packets -v > > By inspection, dhclient will fail to trim old data from its client > leases file when rewriting that file with a lesser amount of data than > it currently contains. See the ftruncate() call in > dhclient.c:rewrite_client_leases(). > > The attached patch adds CAP_FCNTL to the limited rights established for > non-append, write-only files used by tcpdump and dhclient. It also > restricts the fcntl rights to CAP_FCNTL_GETFL. > > The current need to have CAP_FCNTL rights in order to get or set the > file position on non-append, write-only files is subtle. Perhaps part > of the answer is to define a CAP_FSEEK right in sys/capability.h that > resolves to CAP_SEEK|CAP_FCNTL, or to modify the CAP_SEEK description in > rights(4) to note the need for CAP_FCNTL when using ftell() and friends. > > -Patrick Stdio code use fcntl(F_GETFL) already in many places, f.e. fdopen(), freopen(). libc code in general use it in rpc code. According to your note, all that places are currently broken in anyway. 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. -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
