ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

Ryan Stone-2
I have written a short test program that runs unlinkat(2) in
capability mode and fails due to not having the write capabilities:

https://people.freebsd.org/~rstone/src/unlink.c

If I run the binary under ktrace and look at the kdump output, it
gives the following incorrect output:

43775 unlink   CALL  unlinkat(0x3,0x7fffffffe995,0)
43775 unlink   NAMI  "from.QAUlAA0"
43775 unlink   CAP   operation requires CAP_LOOKUP, descriptor holds CAP_LOOKUP
43775 unlink   RET   unlinkat -1 errno 93 Capabilities insufficient

The message should instead say that the operation requires
CAP_UNLINKAT.  Looking at sys/capsicum.h, I suspect that the problem
is related to the strange definition of CAP_UNLINKAT:

#define CAP_UNLINKAT (CAP_LOOKUP | 0x0000000010000000ULL)

I have observed the same problem with renameat(2) and
CAP_RENAMEAT_SOURCE and CAP_RENAMEAT_TARGET:

https://people.freebsd.org/~rstone/src/rename.c
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

Sergey Kandaurov-2
On Sat, Sep 21, 2019 at 08:43:58PM -0400, Ryan Stone wrote:

> I have written a short test program that runs unlinkat(2) in
> capability mode and fails due to not having the write capabilities:
>
> https://people.freebsd.org/~rstone/src/unlink.c
>
> If I run the binary under ktrace and look at the kdump output, it
> gives the following incorrect output:
>
> 43775 unlink   CALL  unlinkat(0x3,0x7fffffffe995,0)
> 43775 unlink   NAMI  "from.QAUlAA0"
> 43775 unlink   CAP   operation requires CAP_LOOKUP, descriptor holds CAP_LOOKUP
> 43775 unlink   RET   unlinkat -1 errno 93 Capabilities insufficient
>
> The message should instead say that the operation requires
> CAP_UNLINKAT.  Looking at sys/capsicum.h, I suspect that the problem
> is related to the strange definition of CAP_UNLINKAT:
>
> #define CAP_UNLINKAT (CAP_LOOKUP | 0x0000000010000000ULL)

FYI, with this grep it was able to decode capabilities.

Index: lib/libsysdecode/mktables
===================================================================
--- lib/libsysdecode/mktables (revision 352685)
+++ lib/libsysdecode/mktables (working copy)
@@ -157,7 +157,7 @@
 gen_table "sigcode"         "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"       "sys/signal.h"
 gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"           "sys/umtx.h"
 gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"    "sys/umtx.h"
-gen_table "caprights"       "CAP_[A-Z_]+[[:space:]]+CAPRIGHT\([0-9],[[:space:]]+0x[0-9]{16}ULL\)"   "sys/capsicum.h"
+gen_table "caprights"       "CAP_[A-Z_]+[[:space:]]+(CAPRIGHT|[()A-Z_|[:space:]]+CAP_LOOKUP)"   "sys/capsicum.h"
 gen_table "sctpprpolicy"    "SCTP_PR_SCTP_[A-Z_]+[[:space:]]+0x[0-9]+"     "netinet/sctp_uio.h" "SCTP_PR_SCTP_ALL"
 gen_table "cmsgtypesocket"  "SCM_[A-Z_]+[[:space:]]+0x[0-9]+"              "sys/socket.h"
 if [ -e "${include_dir}/x86/sysarch.h" ]; then

On unlink.c, it gives:
 45494 unlink   CALL  cap_rights_limit(0x3,0x7fffffffead0)
 45494 unlink   STRU  cap_rights_t CAP_LOOKUP
 45494 unlink   RET   cap_rights_limit 0
 45494 unlink   CALL  openat(AT_FDCWD,0x200323,0<O_RDONLY>)
 45494 unlink   NAMI  "/tmp"
 45494 unlink   RET   openat 4
 45494 unlink   CALL  cap_rights_limit(0x4,0x7fffffffead0)
 45494 unlink   STRU  cap_rights_t CAP_LOOKUP,CAP_UNLINKAT
 45494 unlink   RET   cap_rights_limit 0
 45494 unlink   CALL  cap_enter
 45494 unlink   RET   cap_enter 0
 45494 unlink   CALL  unlinkat(0x3,0x7fffffffeaa5,0)
 45494 unlink   NAMI  "from.YG6jQx2"
 45494 unlink   CAP   operation requires CAP_LOOKUP,CAP_UNLINKAT, descriptor holds CAP_LOOKUP

> I have observed the same problem with renameat(2) and
> CAP_RENAMEAT_SOURCE and CAP_RENAMEAT_TARGET:
>
> https://people.freebsd.org/~rstone/src/rename.c

 49410 rename   CAP   operation requires CAP_LOOKUP,CAP_RENAMEAT_SOURCE, descriptor holds CAP_LOOKUP
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

John Baldwin
On 9/25/19 10:33 AM, Sergey Kandaurov wrote:

> On Sat, Sep 21, 2019 at 08:43:58PM -0400, Ryan Stone wrote:
>> I have written a short test program that runs unlinkat(2) in
>> capability mode and fails due to not having the write capabilities:
>>
>> https://people.freebsd.org/~rstone/src/unlink.c
>>
>> If I run the binary under ktrace and look at the kdump output, it
>> gives the following incorrect output:
>>
>> 43775 unlink   CALL  unlinkat(0x3,0x7fffffffe995,0)
>> 43775 unlink   NAMI  "from.QAUlAA0"
>> 43775 unlink   CAP   operation requires CAP_LOOKUP, descriptor holds CAP_LOOKUP
>> 43775 unlink   RET   unlinkat -1 errno 93 Capabilities insufficient
>>
>> The message should instead say that the operation requires
>> CAP_UNLINKAT.  Looking at sys/capsicum.h, I suspect that the problem
>> is related to the strange definition of CAP_UNLINKAT:
>>
>> #define CAP_UNLINKAT (CAP_LOOKUP | 0x0000000010000000ULL)
>
> FYI, with this grep it was able to decode capabilities.
>
> Index: lib/libsysdecode/mktables
> ===================================================================
> --- lib/libsysdecode/mktables (revision 352685)
> +++ lib/libsysdecode/mktables (working copy)
> @@ -157,7 +157,7 @@
>  gen_table "sigcode"         "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"       "sys/signal.h"
>  gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"           "sys/umtx.h"
>  gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"    "sys/umtx.h"
> -gen_table "caprights"       "CAP_[A-Z_]+[[:space:]]+CAPRIGHT\([0-9],[[:space:]]+0x[0-9]{16}ULL\)"   "sys/capsicum.h"
> +gen_table "caprights"       "CAP_[A-Z_]+[[:space:]]+(CAPRIGHT|[()A-Z_|[:space:]]+CAP_LOOKUP)"   "sys/capsicum.h"
>  gen_table "sctpprpolicy"    "SCTP_PR_SCTP_[A-Z_]+[[:space:]]+0x[0-9]+"     "netinet/sctp_uio.h" "SCTP_PR_SCTP_ALL"
>  gen_table "cmsgtypesocket"  "SCM_[A-Z_]+[[:space:]]+0x[0-9]+"              "sys/socket.h"
>  if [ -e "${include_dir}/x86/sysarch.h" ]; then

CAP_SEEK and CAP_MMAP_X might also be subject to this.  However, I'm not quite
understanding the regex, or at least why the modified portion of the regex isn't
something like this:

(CAPRIGHT\(|\(CAP_LOOKUP)

That is, you currently have [()A-Z_|[:space:]]+ for an expression that I think
will only ever match a single '(' character.

A more general form that might work for CAP_SEEK and CAP_MMAP_X might be
to match on 'CAP_<foo> | 0x<constant)', so something like:

(CAPRIGHT\(|\([^)]*CAP_[A-Z_]+ \| 0x[0-9]+)

--
John Baldwin
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"
Reply | Threaded
Open this post in threaded view
|

Re: ktrace/kdump give incorrect message on unlinkat() failure due to capabilities

Sergey Kandaurov-2
On Mon, Oct 07, 2019 at 09:48:16AM -0700, John Baldwin wrote:

> On 9/25/19 10:33 AM, Sergey Kandaurov wrote:
> >
> > Index: lib/libsysdecode/mktables
> > ===================================================================
> > --- lib/libsysdecode/mktables (revision 352685)
> > +++ lib/libsysdecode/mktables (working copy)
> > @@ -157,7 +157,7 @@
> >  gen_table "sigcode"         "SI_[A-Z]+[[:space:]]+0(x[0-9abcdef]+)?"       "sys/signal.h"
> >  gen_table "umtxcvwaitflags" "CVWAIT_[A-Z_]+[[:space:]]+0x[0-9]+"           "sys/umtx.h"
> >  gen_table "umtxrwlockflags" "URWLOCK_PREFER_READER[[:space:]]+0x[0-9]+"    "sys/umtx.h"
> > -gen_table "caprights"       "CAP_[A-Z_]+[[:space:]]+CAPRIGHT\([0-9],[[:space:]]+0x[0-9]{16}ULL\)"   "sys/capsicum.h"
> > +gen_table "caprights"       "CAP_[A-Z_]+[[:space:]]+(CAPRIGHT|[()A-Z_|[:space:]]+CAP_LOOKUP)"   "sys/capsicum.h"
> >  gen_table "sctpprpolicy"    "SCTP_PR_SCTP_[A-Z_]+[[:space:]]+0x[0-9]+"     "netinet/sctp_uio.h" "SCTP_PR_SCTP_ALL"
> >  gen_table "cmsgtypesocket"  "SCM_[A-Z_]+[[:space:]]+0x[0-9]+"              "sys/socket.h"
> >  if [ -e "${include_dir}/x86/sysarch.h" ]; then
>
> CAP_SEEK and CAP_MMAP_X might also be subject to this.  However, I'm not quite
> understanding the regex, or at least why the modified portion of the regex isn't
> something like this:
>
> (CAPRIGHT\(|\(CAP_LOOKUP)

This won't match against CAP_LOOKUP on the right side, as in CAP_FSTATAT,
but since it is built from CAP_FSTAT and CAP_LOOKUP, it should be fine still.

> That is, you currently have [()A-Z_|[:space:]]+ for an expression that I think
> will only ever match a single '(' character.

All this sad magic is for preceding characters before CAP_LOOKUP,
such as in "(CAP_FSTAT | CAP_LOOKUP".  But seems it isn't needed.

> A more general form that might work for CAP_SEEK and CAP_MMAP_X might be
> to match on 'CAP_<foo> | 0x<constant)', so something like:
>
> (CAPRIGHT\(|\([^)]*CAP_[A-Z_]+ \| 0x[0-9]+)

Given the above, it looks fine.
_______________________________________________
[hidden email] mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[hidden email]"