Please tell me what security problem unveil is solving in this program.
Vevy Kod <vevy...@laposte.net> wrote:
> How about adding an environment variable containing all directories
> where headers can be found ?
> If it is not provided, we can fall back to the per-file algorithm,
> possibly going above limit.
> If a user goes above that limit, they can provide their own list of
> directories.
> And in the worst case, they can simply set it to '/', giving
> themselves read access to everything.
>
> On 18/07/2024 17:43, Lorenz (xha) wrote:
> > the HARE_TD_<files> are the "typedef" files, basically the equivalent
> > to C headers, but automatically generated by the compiler so we can
> > do resolution of types/functions/etc. in dependencies without having
> > to look at the source files themselves.
> > i doubt that anyone is ever going to make use of more than 125
> > imports.
> > the problem is that i cannot simply restict that to one folder. they
> > could be anywhere (even though they are not usually). that'd complicate
> > the patch a lot for... allowing more than 125 imports?
> > the error message will not be particularly hard to read; i guess if
> > someone really hits the limit, we can do something about it then?
> > we don't want to do anything in upstream harec because we want to
> > keep it to the POSIX subset.
> > On Thu, Jul 18, 2024 at 09:29:39AM -0600, Theo de Raadt wrote:
> >> Tobias Heider <tobias.hei...@stusta.de> wrote:
> >>
> >>> I think unveil might still be useful.
> >>
> >> I don't think so.
> >>
> >>> 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
> >>>>
> >>
> >> So the undocumented, un-exported, unveil limit today is 128. This comes
> >> with a cost, so we will not be increasing it.
> >>
> >> Enough setenv, enough arguments, and it fails. Now how does someone
> >> "workaround"
> >> it in their build tooling?
> >>
> >> THAT "workaround" is what makes the solution.
> >>
> >> This is not what unveil is intended to support.
> >
