What OpenSolaris discuss list should _this_ sub-thread move to?
On Fri, Jan 26, 2007 at 06:09:56PM +0100, Casper.Dik at Sun.COM wrote:
> I hadn't looked at the security issue of the agent thread from that
> perspective; I find the whole "agent thread" a bug, not a feature.
I think it's a feature but a bug for the proc tools to rely on it.
I.e., I think it's a feature that 3rd party applications could use as a
sort of _IPC_, but I agree with you on the remainder of you analysis.
> [...]
Right, so, proc tools don't work on victims that have reduced L where
the proc tool requires a certain privilege to be available in the
victim's oE. Ouch.
> >The most obvious way to make psetenv(1) work would require enhancing the
> >agent thread environment so that for _some_ tasks (where security is not
> >an issue, and I think modifying the victim's environ is one such task)
> >one could load code and link it with the application's link map list.
>
> I fear dragons:
>
> - the agent lwp must in this case run concurrently with the other
> threads in the process because the environment and heap
> locking protocols must be honored
Yes, I forgot to mention that, but that's implied (long before you could
even get to putenv() you'd have to have used the victim's rtld, and that
too means not stopping the other threads, or at least very careful
synchronization).
> - single threaded processes have some optimizations required to
> prevent performance regressions (severe enough to be patched
> back into S10; these optimizations can only be done when there is
> NO WAY that a thread gets magically created through a means
> other than *thread_create.
And we can't have a fiction of creating a thread as by a call to
pthread_create() in a signal handler, right?
> - applications may assume getenv("PATH") will always return the
> same value
Including shells. So psetenv(1) really only helps prior to an exec(2).
But for PATH it would help with exec*p(2) with apps that don't implement
PATH searching themselves.
> >(BTW, a special rtld for agent threads would make it a lot easier to
> >write proc tools too, but wouldn't help in this case since modifying the
> >victim's environ kinda requires being linked with the victim's libc.)
>
> Ceterum Censeo, agent threads must die.
Heh.
Nico
--
