Messages in this thread | | | Date | Tue, 5 Apr 2022 18:09:03 +0200 | From | Mickaël Salaün <> | Subject | Re: [GIT PULL] Add trusted_for(2) (was O_MAYEXEC) |
| |
On 05/04/2022 01:26, Linus Torvalds wrote: > On Mon, Apr 4, 2022 at 3:25 PM Kees Cook <keescook@chromium.org> wrote:
[...]
> >> I think this already exists as AT_EACCESS? It was added with >> faccessat2() itself, if I'm reading the history correctly. > > Yeah, I noticed myself, I just hadn't looked (and I don't do enough > user-space programming to be aware of if that way).
I think AT_EACCESS should be usable with the new EXECVE_OK too.
> >>> (a) "what about suid bits that user space cannot react to" >> >> What do you mean here? Do you mean setid bits on the file itself? > > Right. > > Maybe we don't care.
I think we don't. I think the only corner case that could be different is for files that are executable, SUID and non-readable. In this case it wouldn't matter because userspace could not read the file, which is required for interpretation/execution. Anyway, S[GU]ID bits in scripts are just ignored by execve and we want to follow the same semantic.
> > Maybe we do. > > Is the user-space loader going to honor them? Is it going to ignore > them? I don't know. And it actually interacts with things like > 'nosuid', which the kernel does know about, and user space has a hard > time figuring out. > > So if the point is "give me an interface so that I can do the same > thing a kernel execve() loader would do", then those sgid/suid bits > actually may be exactly the kind of thing that user space wants the > kernel to react to - should it ignore them, or should it do something > special when it sees that they are set? > > I'm not saying that they *should* be something we care about. All I'm > saying is that I want that *discussion* to happen. > > Linus
| |