[kernel-hardening] How to temporary change 'current' (task)

[kernel-hardening] How to temporary change 'current' (task)

[Vasiliy Kulikov]

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

Re: [kernel-hardening] How to temporary change 'current' (task)

[Solar Designer]

Vasiliy,

On Fri, Jun 17, 2011 at 12:36:51PM +0400, Vasiliy Kulikov wrote:
> 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 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

Re: [kernel-hardening] How to temporary change 'current' (task)

[Vasiliy Kulikov]

On Fri, Jun 17, 2011 at 12:59 +0400, Solar Designer wrote:
> On Fri, Jun 17, 2011 at 12:36:51PM +0400, Vasiliy Kulikov wrote:
> > 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 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.

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

Re: [kernel-hardening] How to temporary change 'current' (task)

[Vasiliy Kulikov]

On Fri, Jun 17, 2011 at 13:25 +0400, Vasiliy Kulikov wrote:
> On Fri, Jun 17, 2011 at 12:59 +0400, Solar Designer wrote:
> > On Fri, Jun 17, 2011 at 12:36:51PM +0400, Vasiliy Kulikov wrote:
> > > I wonder whether there is a simple way to temporary switch 'current' to
> > > another task and then switch it back with minimum side effects?

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

Re: [kernel-hardening] How to temporary change 'current' (task)

[Vasiliy Kulikov]

On Fri, Jun 17, 2011 at 14:01 +0400, Vasiliy Kulikov wrote:
>     kernel.proc_restricted
> 
>     kernel.proc_restricted_gid

Or even kernel.procinfo_restricted{,gid}.

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

[kernel-hardening] Re: How to temporary change 'current' (task)

[Peter Zijlstra]

On Fri, 2011-06-17 at 12:36 +0400, Vasiliy Kulikov wrote:
> 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? 

No.

>  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.

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.

[kernel-hardening] Re: How to temporary change 'current' (task)

[Vasiliy Kulikov]

On Fri, Jun 17, 2011 at 11:29 +0200, Peter Zijlstra wrote:
> On Fri, 2011-06-17 at 12:36 +0400, Vasiliy Kulikov wrote:
> > I wonder whether there is a simple way to temporary switch 'current' to
> > another task and then switch it back with minimum side effects? 
> 
> No.

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

> >  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.
> 
> 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.

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