1. We do not need a good reason to reduce our attack surface. The 
likeliness of the scenarios we are preventing does not matter: those 
scenarios will become likely as soon as they become the easiest to exploit.

2. It prevents unknowingly escalating a supply-chain attack. If a 
malware is somehow embedded in the compiler, it will be able to 1) read 
secret keys used by developers to sign binary packages, and 2) embed 
those secret keys in the compiler output (likely set for distribution).

Of course, that specific scenario can already be prevented in theory, 
using file permissions. But more security will not hurt.

On 18/07/2024 19:55, Theo de Raadt wrote:
> Please tell me what security problem unveil is solving in this program.
> 
> Vevy Kod <vevykod@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.heider@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.
>>>

• OpenPGP_0x02796D87FACEDF43.asc (685B)