Messages in this thread |  | | Subject | Re: kernel BUG at kernel/cred.c:434! | From | Casey Schaufler <> | Date | Wed, 17 Apr 2019 09:42:11 -0700 |
| |
On 4/17/2019 9:27 AM, Oleg Nesterov wrote: > On 04/17, Paul Moore wrote: >> On Wed, Apr 17, 2019 at 10:57 AM Oleg Nesterov <oleg@redhat.com> wrote: >>> On 04/17, Paul Moore wrote: >>>> I'm tempted to simply return an error in selinux_setprocattr() if >>>> the task's credentials are not the same as its real_cred; >>> What about other modules? I have no idea what smack_setprocattr() is, >>> but it too does prepare_creds/commit creds. >>> >>> it seems that the simplest workaround should simply add the additional >>> cred == real_cred into proc_pid_attr_write(). >> Yes, that is simple, but I worry about what other LSMs might want to >> do. While I believe failing if the effective creds are not the same >> as the real_creds is okay for SELinux (possibly Smack too), I worry >> about what other LSMs may want to do. After all, >> proc_pid_attr_write() doesn't change the the creds itself, that is >> something the specific LSMs do. > Yes, but if proc_pid_attr_write() is called with cred != real_cred then > something is already wrong? > > In fact, I think that something is already wrong if it is not called by > user-space directly. Too late to ask, but why is this /proc/self/attr/ > magic not implemented via syscall(s) ?
Shell scripts, for one thing. It's a straightforward and appropriate use of the /proc interface. System calls would require additional change to existing programs, whereas using the /proc interface allows a good deal to be done in the containing scripts.
|  |