Re: [PATCH] prctl: remove one-shot limitation for changing exe link

[Stanislav Kinsburskiy]

25.07.2016 20:21, Eric W. Biederman пишет:
> Stanislav Kinsburskiy <skinsbursky@xxxxxxxxxxxxx> writes:
>
> > Gentlemen,
> >
> > Looks like there are no objections to this patch.
> There has been objection.
>
> The only justification for the change that has been put forward is
> someone doing a restore lazily.  I don't see a reason why you can't call
> prctl_set_mm_exe_file until you have the file in place instead of a
> place holder that sounds like a trivial solution to any restore issues.

If I understand your proposal correctly, you mean, that the call to
prctl_set_mm_exe_file can be posponed till the actual file is in place.
It can be done this way you propose (although it's ugly).
But you objection looks like you want to preserve some behavior you 
believe is reliable.
But it's not.

> The truth is an unlimited settable exe link is essentially meaningless,
> as you can't depend on it for anything.  One shot seems the best
> compromise I have seen put forward between the definite
> checkpoint/restart requirement to set the this value and the general
> need to have something that makes sense and people can depend on for
> system management.

Depending on exe link for system management is useful, but can't be 
reliable and
can't prevent malicious software to compromise the system.
If we wouldn't have the ability to change exe link, than the only thing 
we could be sure,
that process at least started with the binary we believe is reliable.

But since we can change it, the only thing we can rely now is the file 
is executable
and process have permissions to execute it.
And this guarantee in preserved across any amount of exe link replacement.

> Also there is a big fat bug in prctl_set_mm_exe_file.  It doesn't
> validate that the new file is a actually mmaped executable.  We would
> definitely need that to be fixed before even considering removing the
> limit.

Why do we need it? To guarantee, that process has read permission to the 
file?


> Right now all I see is people involved in the implementation details of
> their own little feature
>
> So for the patch I am responding to:
> Nacked-by: "Eric W. Biederman" <ebiederm@xxxxxxxxxxxx>
>
> Plus the merge window is open so no one is taking any patches right now.
> It is the time to take what has already been staged and get that code
> merged.
>
> Eric