Index | Thread | Search

From:
"Theo de Raadt" <deraadt@openbsd.org>
Subject:
Re: openat(2) is mostly useless, sadly
To:
"H. Hartzer" <h@hartzer.sh>
Cc:
tech@openbsd.org
Date:
Sun, 01 Jun 2025 15:46:18 -0600

Download raw body.

Thread
  • H. Hartzer:

    openat(2) is mostly useless, sadly

    • Theo de Raadt:

      openat(2) is mostly useless, sadly

  • H. Hartzer <h@hartzer.sh> wrote:
    
    > I wrote a small test program for this. I only ran it as root, so maybe
    > that changes something, but I could not get the chroot-like
    > functionality to work. I'm able to chdir right back out.
    
    I write the diff to handle the *at() system calls.
    
    I said it might be nice that it works on other things too, but I never
    validated that.
    
    sys_chdir() and probably most other non-*at() calls do their own namei()
    operations without ni_dirfd being set to indicate what is going on, so
    completing such a chroot-for-regular-users apparently will require more
    kernel changes.  
    
    In particular, the changes only occur inside this block:
    
    +       if (ndp->ni_dirfd != AT_FDCWD) {
    
    Since those system calls operate inside AT_FDCWD, it could be many changes,
    or maybe we can create a new in-kernel value which isn't AT_FDCWD, but acts
    similar or different depending upon context:
    
    /sys/sys/namei.h:       ndinitat(ndp, op, flags, segflp, AT_FDCWD, namep, p)
    
    The main purpose of the diff was *NOT* to make a anyone-chroot, but to
    for the first time all the *at() system calls to be used as a component
    of a security boundary.  Today, *at() are used extremely rarely, weirdly
    the most common pattern is to get access to the flags which are not present
    in the older system calls:
    
    #define AT_EACCESS              0x01
    #define AT_SYMLINK_NOFOLLOW     0x02
    #define AT_SYMLINK_FOLLOW       0x04
    #define AT_REMOVEDIR            0x08
    
    
  • H. Hartzer:

    openat(2) is mostly useless, sadly