On Tue, May 26, 2020 at 08:58:16AM -0600, Theo de Raadt wrote:
> > firefox[50499]: pledge "", syscall 203
>
> This is mlock.
>
> It is not suitable in a privsep + pledge program.
>
> pledge challenges programs to be narrower and more careful in their
> system call use for two reasons: upon error they can cause less damage
> within the filesystem, and upon control fewer kernel subsystems can be
> reached causing even more grave problems.
>
> My position is that a *user program* should not exclusively reserve a
> physical resource, as physical resources are supposed to be *shared*
>
> This probably comes out of a library. The concept is: pull a library
> written by who knows who, surely full of leaky abstractions and a weak
> implimentation of the rules of behaviour, into a monster program.
>
> And hope for a good outcome.
>
> In the greater open source community, every large program and library
> must use every shiny system call, because that large program is surely
> the only program running, and when it is running, it is the most
> important piece of software in the universe. When you are a pig
> resource sharing is a stupid idea, right?
>
> mlock(0, ~0);
>
> Maybe ls and cat should use mlock? Maybe ksh. How about we just call
> mlock inside malloc?
>
> I've gone so far as to consider making mlock() as non-root be a NOP,
> simply return 0.
>
> There is a disease in this source code development industry.
Maybe opensc upstream have valid reasons for calling mlock() or not, i'm
not in a position to judge that.
Anyway, the corresponding code is probably there:
https://github.com/OpenSC/OpenSC/blob/master/src/libopensc/sc.c#L895
Which was added 2 years ago in this PR, with subject 'Added memory
locking for secrets': https://github.com/OpenSC/OpenSC/pull/1491/files
And fwiw, i recently had exchanges with someone else trying to use an
estonian id card, so it seems this usecase is 'common'. Maybe
fixing/looking at opensc is the way to go.
Landry
No comments:
Post a Comment