Subject: Re: O_REG_ONLY, O_NOFOLLOW, open_ass(), and other such beasts
To: None <tech-kern@netbsd.org>
From: Christos Zoulas <christos@zoulas.com>
List: tech-kern
Date: 12/06/2000 00:44:32
In article <200012051927.eB5JRc100815@trinity.ihack.net>,
Charles M. Hannum <root@ihack.net> wrote:
>
>My conclusions from this are three-fold
>
>* O_REG_ONLY is not terribly useful (except perhaps in place of using
>  O_NDELAY/O_NONBLOCK), and the proper approach is to thoroughly audit
>  libraries to make sure they are doing UID swapping where
>  appropriate.

I've implemented the O_NDELAY stuff in our stdio, but I would prefer
to have something cleaner such as O_REGONLY. The problem is that
it becomes a bit tedious to turn O_NDELAY on/off, such as in the
case of fdopen() [yes it is pretty simple to code, but it adds more
complexity].

Every program that wishes to just open regular files [as opposed
to devices, sockets, named pipes, directories] needs to go through
the open/fstat/fcntl crap, which can easily be avoided by O_REGONLY.
In addition there is always the signal/thread considerations when
doing multiple system calls that need to happen in a non-interrupted
context. Since O_REGONLY is using just a single system call it avoids
the overhead of having to call sigblock/sigprocmask around the three
syscalls altogether.

I believe that there is a benefit from going through libc functions
such as ones that involve TERMCAP/HOSTALIASES/TZ/ etc and adding
O_REGONLY to the open calls, to avoid denial of service attacks.
It is a lot simpler than having to repeat the code for fstat/fcntl
on each one.

I did not implement the O_NDELAY stuff to improve security in setuid
program case. I implemented it so that things such as /etc/security
don't get stuck opening named pipes and cannot be coerced to affect
devices. I think that it is not easy to fix the /etc/daily and /etc/security
problems without suck a facility. There are no race issues in that
scenario, and I am not presenting the O_REGONLY flag as a solution
to the setuid() problem.

[stuff deleted]

>* Readers may have noticed I didn't mention open_as() anywhere else.
>  Draw your own conclusions on that.

I totally agree with the implied conclusion of the above statement.

christos