On Thu, Jul 18, 2024 at 12:59:15PM +0100, Stuart Henderson wrote:
> On 2024/07/18 05:27, Theo de Raadt wrote:
> > This is not right.
> >
> > Only a maximum number of unveil's are allowed, before it starts returning
> > E2BIG. That amount is not a public #define, to discourage what you are
> > doing.
> >
> > You are trying to shove an unbounded number of them into the kernel, based
> > upon getenv and argv.
> >
> > When you run out, and will exit with error. That's not very nice is it?
> >
>
> I think the place where unveil really gives the most benefit is for
> software which needs both network and filesystem access in the same
> process. Much of the protection that Lorenz is looking for would come
> from pledge without needing to consider unveil.
I think unveil might still be useful.
As I understand Theo the problem is just that calling unveil per-input file to
grant
read access won't work. Restricting write and create permissions to the single
well-known output directory still makes sense to me.
>
> The set of library functions used is pretty small, so it should be easy
> enough to reason about adding pledge.
>
> $ nm -s /usr/local/bin/harec | awk '/^ *U / { print $2 }' | column
> __assert2 atexit fseek memset strerror
> __errno bsearch fstat open_memstream strlen
> __isinf calloc getenv optarg strncmp
> __isinff exit getline optind strtod
> __isinfl fclose getopt perror strtoul
> __isnan feof isalnum qsort
> strtoumax
> __isnanf fgetc isalpha realloc vfprintf
> __isnanl fileno isatty snprintf vsnprintf
> __isthreaded fmemopen isdigit stat
> __sF fopen isprint strchr
> _csu_finish fread memcmp strcmp
> abort free memcpy strdup
>
