How to temporary change 'current' (task)

Hi,

I wonder whether there is a simple way to temporary switch 'current' to another task and then switch it back with minimum side effects? I need it to call "reversed" ptrace_may_access() with swapped current and target task. Introducing ptrace_task_may_access_me() would produce too much noise in LSM (it also needs reversed security_ptrace_access_check()), which is too loud for my needs.

Specifically, I need it to filter taskstats and proc connector requests for a restriction of getting other processes' information:

http://permalink.gmane.org/gmane.linux.kernel/1155354

As the check is handled in the context of the ptrace target process, ptrace_may_access() doesn't fit my needs.

Thanks,

Vasiliy

Vasiliy,

I strongly recommend that we don't. Doing so would introduce security risks similar to what we saw with set_fs(USER_DS). Even if you implement everything right and safely, you would set an extremely bad precedent, encouraging others to do risky things like that. Under the security hardening project, we should be moving the kernel away from those things, not introducing more of them.

So you need to find another way to achieve your objective (or maybe choose not to achieve it).

...and you meant "temporarily". ;-)

Sorry for not answering your question directly (I don't know the answer), yet I hope this opinion helps.

Alexander

Yes, you might be right, but it looks like the most simple solution. In the netlink listeners case the task triggers a broadcast message (on exec(), fork(), setuid(), etc.) and delivers the message to the listeners. The official way to filter these messages (actually, skbs) is providing a filter function to netlink_broadcast_filter(). This filter would do ptrace_may_access()-like check. The check would be processes in the context of the emmitter process (ptrace target).

Arbitrary filtering on the receivers' side looks technically rather difficult and unreasonable to me and unlikely to be applied.

Much more simple, but dubious solution is disabling such netlink sockets for unprivileged users. This would deny harmless process tracking for the same user without any actual need.

Thanks,

Vasiliy

BTW, as HARDEN_PROC restricts not only procfs, but also netlink sockets, it should be moved into sysctls. I think about (according to already implemented dmesg_restricted and kptr_restricted):

kernel.proc_restricted

kernel.proc_restricted_gid

And, as net restriction is no more associated with proc restrictions:

net.core.conninfo_restricted

net.core.conninfo_restricted_gid

Thanks,

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

Or even kernel.procinfo_restricted{,gid}.

Vasiliy Kulikov
http://www.openwall.com - bringing security into open computing environments

No.

looking at __ptrace_may_access() it doesn't look too hard to make it take two task arguments and use __task_cred() twice instead of current_cred().

It of course needs extending security_ptrace_access_check() as well, but that comes with the territory.

After a moment's thought, it would also break some synchronization that relies on some structures are accesses only from the current task.

Well, yes, but it implies pushing explicit ptrace actor into LSM modules. OK, it should be not as noisy as I initially thought - almost all current LSMs already use "current" as an explicit argument in theirs internal functions.

Thank you,

Vasiliy