| Message ID | 20200910164612.114215-1-mic@digikod.net (mailing list archive) |
|---|---|
| Headers | show |
| Series | Add introspect_access(2) (was O_MAYEXEC) | expand |
On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote: > This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC > series with a new syscall: introspect_access(2) . Access check are now > only possible on a file descriptor, which enable to avoid possible race > conditions in user space. But introspection is about examining _yourself_. This isn't about doing that. It's about doing ... something ... to a script that you're going to execute. If the script were going to call the syscall, then it might be introspection. Or if the interpreter were measuring itself, that would be introspection. But neither of those would be useful things to do, because an attacker could simply avoid doing them. So, bad name. What might be better? sys_security_check()? sys_measure()? sys_verify_fd()? I don't know.
On 10/09/2020 19:04, Matthew Wilcox wrote: > On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote: >> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC >> series with a new syscall: introspect_access(2) . Access check are now >> only possible on a file descriptor, which enable to avoid possible race >> conditions in user space. > > But introspection is about examining _yourself_. This isn't about > doing that. It's about doing ... something ... to a script that you're > going to execute. If the script were going to call the syscall, then > it might be introspection. Or if the interpreter were measuring itself, > that would be introspection. But neither of those would be useful things > to do, because an attacker could simply avoid doing them. Picking a good name other than "access" (or faccessat2) is not easy. The idea with introspect_access() is for the calling task to ask the kernel if this task should allows to do give access to a kernel resource which is already available to this task. In this sense, we think that introspection makes sense because it is the choice of the task to allow or deny an access. > > So, bad name. What might be better? sys_security_check()? > sys_measure()? sys_verify_fd()? I don't know. > "security_check" looks quite broad, "measure" doesn't make sense here, "verify_fd" doesn't reflect that it is an access check. Yes, not easy, but if this is the only concern we are on the good track. :) Other ideas: - interpret_access (mainly, but not only, for interpreters) - indirect_access - may_access - faccessat3
On 10/09/2020 19:21, Mickaël Salaün wrote: > > On 10/09/2020 19:04, Matthew Wilcox wrote: >> On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote: >>> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC >>> series with a new syscall: introspect_access(2) . Access check are now >>> only possible on a file descriptor, which enable to avoid possible race >>> conditions in user space. >> >> But introspection is about examining _yourself_. This isn't about >> doing that. It's about doing ... something ... to a script that you're >> going to execute. If the script were going to call the syscall, then >> it might be introspection. Or if the interpreter were measuring itself, >> that would be introspection. But neither of those would be useful things >> to do, because an attacker could simply avoid doing them. > > Picking a good name other than "access" (or faccessat2) is not easy. The > idea with introspect_access() is for the calling task to ask the kernel > if this task should allows to do give access to a kernel resource which > is already available to this task. In this sense, we think that > introspection makes sense because it is the choice of the task to allow > or deny an access. > >> >> So, bad name. What might be better? sys_security_check()? >> sys_measure()? sys_verify_fd()? I don't know. >> > > "security_check" looks quite broad, "measure" doesn't make sense here, > "verify_fd" doesn't reflect that it is an access check. Yes, not easy, > but if this is the only concern we are on the good track. :) > > > Other ideas: > - interpret_access (mainly, but not only, for interpreters) > - indirect_access > - may_access > - faccessat3 > I think that entrusted_access(2) looks good. What do you think?
On Thu, 2020-09-10 at 19:21 +0200, Mickaël Salaün wrote: > On 10/09/2020 19:04, Matthew Wilcox wrote: > > On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote: > >> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC > >> series with a new syscall: introspect_access(2) . Access check are now > >> only possible on a file descriptor, which enable to avoid possible race > >> conditions in user space. > > > > But introspection is about examining _yourself_. This isn't about > > doing that. It's about doing ... something ... to a script that you're > > going to execute. If the script were going to call the syscall, then > > it might be introspection. Or if the interpreter were measuring itself, > > that would be introspection. But neither of those would be useful things > > to do, because an attacker could simply avoid doing them. > Michael, is the confusion here that IMA isn't measuring anything, but verifying the integrity of the file? The usecase, from an IMA perspective, is enforcing a system wide policy requiring everything executed to be signed. In this particular use case, the interpreter is asking the kernel if the script is signed with a permitted key. The signature may be an IMA signature or an EVM portable and immutable signature, based on policy. > Picking a good name other than "access" (or faccessat2) is not easy. The > idea with introspect_access() is for the calling task to ask the kernel > if this task should allows to do give access to a kernel resource which > is already available to this task. In this sense, we think that > introspection makes sense because it is the choice of the task to allow > or deny an access. > > > > > So, bad name. What might be better? sys_security_check()? > > sys_measure()? sys_verify_fd()? I don't know. > > > > "security_check" looks quite broad, "measure" doesn't make sense here, > "verify_fd" doesn't reflect that it is an access check. Yes, not easy, > but if this is the only concern we are on the good track. :) Maybe replacing the term "measure" with "integrity", but rather than "integrity_check", something along the lines of fgetintegrity, freadintegrity, fcheckintegrity. Mimi > > > Other ideas: > - interpret_access (mainly, but not only, for interpreters) > - indirect_access > - may_access > - faccessat3
On 10/09/2020 20:08, Mimi Zohar wrote: > On Thu, 2020-09-10 at 19:21 +0200, Mickaël Salaün wrote: >> On 10/09/2020 19:04, Matthew Wilcox wrote: >>> On Thu, Sep 10, 2020 at 06:46:09PM +0200, Mickaël Salaün wrote: >>>> This ninth patch series rework the previous AT_INTERPRETED and O_MAYEXEC >>>> series with a new syscall: introspect_access(2) . Access check are now >>>> only possible on a file descriptor, which enable to avoid possible race >>>> conditions in user space. >>> >>> But introspection is about examining _yourself_. This isn't about >>> doing that. It's about doing ... something ... to a script that you're >>> going to execute. If the script were going to call the syscall, then >>> it might be introspection. Or if the interpreter were measuring itself, >>> that would be introspection. But neither of those would be useful things >>> to do, because an attacker could simply avoid doing them. >> > > Michael, is the confusion here that IMA isn't measuring anything, but > verifying the integrity of the file? The usecase, from an IMA > perspective, is enforcing a system wide policy requiring everything > executed to be signed. In this particular use case, the interpreter is > asking the kernel if the script is signed with a permitted key. The > signature may be an IMA signature or an EVM portable and immutable > signature, based on policy. There is also the use case of noexec mounts and file permissions. From user space point of view, it doesn't matter which kernel component is in charge of defining the policy. The syscall should then not be tied with a verification/integrity/signature/appraisal vocabulary, but simply an access control one. > >> Picking a good name other than "access" (or faccessat2) is not easy. The >> idea with introspect_access() is for the calling task to ask the kernel >> if this task should allows to do give access to a kernel resource which >> is already available to this task. In this sense, we think that >> introspection makes sense because it is the choice of the task to allow >> or deny an access. >> >>> >>> So, bad name. What might be better? sys_security_check()? >>> sys_measure()? sys_verify_fd()? I don't know. >>> >> >> "security_check" looks quite broad, "measure" doesn't make sense here, >> "verify_fd" doesn't reflect that it is an access check. Yes, not easy, >> but if this is the only concern we are on the good track. :) > > Maybe replacing the term "measure" with "integrity", but rather than > "integrity_check", something along the lines of fgetintegrity, > freadintegrity, fcheckintegrity. What about entrusted_access(2)? It reflects the fact that the kernel delegate to (trusted) user space tasks some access enforcements. > > Mimi > >> >> >> Other ideas: >> - interpret_access (mainly, but not only, for interpreters) >> - indirect_access >> - may_access >> - faccessat3 > >
On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: > There is also the use case of noexec mounts and file permissions. From > user space point of view, it doesn't matter which kernel component is in > charge of defining the policy. The syscall should then not be tied with > a verification/integrity/signature/appraisal vocabulary, but simply an > access control one. permission()?
On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote: > On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: > > There is also the use case of noexec mounts and file permissions. From > > user space point of view, it doesn't matter which kernel component is in > > charge of defining the policy. The syscall should then not be tied with > > a verification/integrity/signature/appraisal vocabulary, but simply an > > access control one. > > permission()? int lsm(int fd, const char *how, char *error, int size); Seriously, this is "ask LSM to apply special policy to file"; let's _not_ mess with flags, etc. for that; give it decent bandwidth and since it's completely opaque for the rest of the kernel, just a pass a string to be parsed by LSM as it sees fit.
On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote: > On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote: > > On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: > > > There is also the use case of noexec mounts and file permissions. From > > > user space point of view, it doesn't matter which kernel component is in > > > charge of defining the policy. The syscall should then not be tied with > > > a verification/integrity/signature/appraisal vocabulary, but simply an > > > access control one. > > > > permission()? > > int lsm(int fd, const char *how, char *error, int size); > > Seriously, this is "ask LSM to apply special policy to file"; let's > _not_ mess with flags, etc. for that; give it decent bandwidth > and since it's completely opaque for the rest of the kernel, > just a pass a string to be parsed by LSM as it sees fit. Hang on, it does have some things which aren't BD^W^WLSM. It lets the interpreter honour the mount -o noexec option. I presume it's not easily defeated by cat /home/salaun/bin/bad.pl | perl -
On 10/09/2020 22:05, Matthew Wilcox wrote: > On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote: >> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote: >>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: >>>> There is also the use case of noexec mounts and file permissions. From >>>> user space point of view, it doesn't matter which kernel component is in >>>> charge of defining the policy. The syscall should then not be tied with >>>> a verification/integrity/signature/appraisal vocabulary, but simply an >>>> access control one. >>> >>> permission()? >> >> int lsm(int fd, const char *how, char *error, int size); >> >> Seriously, this is "ask LSM to apply special policy to file"; let's >> _not_ mess with flags, etc. for that; give it decent bandwidth >> and since it's completely opaque for the rest of the kernel, >> just a pass a string to be parsed by LSM as it sees fit. Well, I don't know why you're so angry against LSM, but as noticed by Matthew, the main focus of this patch series is not about LSM (no hook, no security/* code, only file permission and mount option checks, nothing fancy). Moreover, the syscall you're proposing doesn't make sense, but I guess it's yet another sarcastic reply. Please, cool down. We asked for constructive comments and already followed your previous requests (even if we didn't get answers for some questions), but seriously, this one is nonsense. > > Hang on, it does have some things which aren't BD^W^WLSM. It lets > the interpreter honour the mount -o noexec option. I presume it's > not easily defeated by > cat /home/salaun/bin/bad.pl | perl - > Funny. I know there is a lot of text and links but please read the commit messages before further comments.
On 10.09.2020 23:05, Matthew Wilcox wrote: > On Thu, Sep 10, 2020 at 09:00:10PM +0100, Al Viro wrote: >> On Thu, Sep 10, 2020 at 07:40:33PM +0100, Matthew Wilcox wrote: >>> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: >>>> There is also the use case of noexec mounts and file permissions. From >>>> user space point of view, it doesn't matter which kernel component is in >>>> charge of defining the policy. The syscall should then not be tied with >>>> a verification/integrity/signature/appraisal vocabulary, but simply an >>>> access control one. >>> >>> permission()? >> >> int lsm(int fd, const char *how, char *error, int size); >> >> Seriously, this is "ask LSM to apply special policy to file"; let's >> _not_ mess with flags, etc. for that; give it decent bandwidth >> and since it's completely opaque for the rest of the kernel, >> just a pass a string to be parsed by LSM as it sees fit. > > Hang on, it does have some things which aren't BD^W^WLSM. It lets > the interpreter honour the mount -o noexec option. I presume it's > not easily defeated by > cat /home/salaun/bin/bad.pl | perl - Hi! It could be bypassed this way. There are several ways of executing some script: 1) /unsigned.sh (Already handled by IMA) 2) bash /unsigned.sh (Not handled. Works even with "-o noexec" mount) 3) bash < /unsigned.sh (Not handled. Works even with "-o noexec" mount) 4) cat /unsigned.sh | bash (Not handled. Works even with "-o noexec" mount) AFAIK, the proposed syscall solves #2 and may be #3. As for #4 in security critical environments there should be system-wide options to disable interpreting scripts from the standard input. I suppose, executing commands from the stdin is a rare case, and could be avoided entirely in security critical environments. And yes, some help from the interpreters is needed for that. As for the usage of the system call, I have a proposal to extend its usage to validate systemd unit files. Because a unit file could specify what UID to use for a service, also it contains ExecStartPre which is actually a script and is running as root (for the system session services). For the syscall name it could be: - trusted_file() - trusted_file_content() - valid_file() - file_integrity() because what we are checking here is the file content integrity (IMA) and may be file permissions/attrs integrity (EVM).
On Thu, 10 Sep 2020, Matthew Wilcox wrote: > On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: > > There is also the use case of noexec mounts and file permissions. From > > user space point of view, it doesn't matter which kernel component is in > > charge of defining the policy. The syscall should then not be tied with > > a verification/integrity/signature/appraisal vocabulary, but simply an > > access control one. > > permission()? > The caller is not asking the kernel to grant permission, it's asking "SHOULD I access this file?" The caller doesn't know, for example, if the script file it's about to execute has been signed, or if it's from a noexec mount. It's asking the kernel, which does know. (Note that this could also be extended to reading configuration files). How about: should_faccessat ?
Arnd and Michael, What do you think of "should_faccessat" or "entrusted_faccessat" for this new system call? On 12/09/2020 02:28, James Morris wrote: > On Thu, 10 Sep 2020, Matthew Wilcox wrote: > >> On Thu, Sep 10, 2020 at 08:38:21PM +0200, Mickaël Salaün wrote: >>> There is also the use case of noexec mounts and file permissions. From >>> user space point of view, it doesn't matter which kernel component is in >>> charge of defining the policy. The syscall should then not be tied with >>> a verification/integrity/signature/appraisal vocabulary, but simply an >>> access control one. >> >> permission()? >> > > The caller is not asking the kernel to grant permission, it's asking > "SHOULD I access this file?" > > The caller doesn't know, for example, if the script file it's about to > execute has been signed, or if it's from a noexec mount. It's asking the > kernel, which does know. (Note that this could also be extended to reading > configuration files). > > How about: should_faccessat ? > Sounds good to me.