[PATCH 3] utrace: introduce ENGINE_LSM_ flags

2010-07-07 Thread Oleg Nesterov
Introduce ENGINE_LSM_TRACE and ENGINE_LSM_TRACE_CAP bits for utrace_unsafe_exec(). These bit should be set when we attach the new engine by user request. Note: we use engine-flags and task-utrace_flags, this doesn't really matter. The only important point is: somehow utrace_engine should have the

[PATCH 1] utrace: introduce ENGINE_EXTRA_FLAGS

2010-07-07 Thread Oleg Nesterov
The only patch which probably makes sense anyway. Currently utrace assumes that task-utrace_flags can have only one special bit, ENGINE_STOP. But it make sense to add more special bits. For example, ptrace-utrace. It still uses task-ptrace for PT_PTRACE_CAP and PT_UTRACED (the latter one is only

[PATCH 5] utrace: convert ptrace to use utrace_set_caps()

2010-07-07 Thread Oleg Nesterov
Convert ptrace to use utrace_set_caps(). ptrace_report_clone() uses utrace_get_caps() and PT_UTRACED instead of parent-ptrace. Henceforth task_struct-ptrace is only used for PT_UTRACED, and this bit can be moved into ENGINE_EXTRA_FLAGS. utrace_unsafe_exec() doesn't need to play with task-ptrace

[PATCH 2] utrace: introduce utrace_unsafe_exec()

2010-07-07 Thread Oleg Nesterov
Introduce utrace_unsafe_exec() used by tracehook_unsafe_exec(). Currently the new helper just copies the old -ptrace logic. Whatever we do, we need something like this patch. Once we implement anything which can be used by unprivileged user we should handle the security problems, in particular we

Re: [PATCH 0/6] utrace: security problems

2010-07-07 Thread Roland McGrath
As to the unsafe_exec stuff, I'd long figured we would have something just about like that. (You might recall that an earlier utrace API had an unsafe_exec engine callback, which had its own unresolved complications.) For exec transitions (set-id, file caps, selinux), I'd originally figured an

Re: [PATCH 0/6] utrace: security problems

2010-07-07 Thread Oleg Nesterov
On 07/07, Roland McGrath wrote: For exec transitions (set-id, file caps, selinux), I'd originally figured an engine's report_exec could check for changes and decide to detach itself if appropriate. No, it can't. At this point S_ISUID/S_ISGID exid's were already dropped, or exec can fail

Re: [PATCH 0/6] utrace: security problems

2010-07-07 Thread Roland McGrath
For exec transitions (set-id, file caps, selinux), I'd originally figured an engine's report_exec could check for changes and decide to detach itself if appropriate. No, it can't. At this point S_ISUID/S_ISGID exid's were already dropped, or exec can fail before before