Why don't we create a special class of programs which can break the normal rules?

re: Why don't we create a special class of programs which can break the normal rules?

Anonymous Coward — Tue, 29 Dec 2009 14:43:21 GMT

[While it could ... introduce new ones! -Raymond]

That was not what I was suggesting; I apologize if I was unclear. I was merely suggesting that it is a) possible to give a process special powers (Windows already does this; for example there are processes running on my computer at the moment that don't have regular file access) and b) that you could grant some of those powers if you start a process using Ctrl-Alt-Del. I don't see why that would be a violation of ‘general engineering principles’ since there is nothing particular about the process started that the kernel needs to know, neither does the process need to know anything special to be able to use its special powers. It's just good old permissions.

re: Why don't we create a special class of programs which can break the normal rules?

Anonymous Coward — Mon, 28 Dec 2009 18:36:05 GMT

[The mutexes are ... to release it. -Raymond]

Phew! That's a relief.

So the only real way in which a mutex can screw up task manager is if you manage to suspend it just as it owns some user mode mutex (a mutex set by user mode code - as far as I know it's normally impossible to suspend a thread while it's in kernel mode) that task manager needs too.

To solve that, you would need to make sure that task manager cannot be made to wait on a mutex possibly owned by suspendable code, which may be difficult if for example uxTheme is doing some internal locking. Still, if something like that can happen, something should be done about it, since I suspect the entire system would deadlock, not just task manager.

But until such a situation is found the discussion is academic; I've suspended and resumed processes a lot and never had unrelated processes lock up on me.

>>couldn't task manager be rewritten inside of win32k.sys?

>Oh no!!! How will it be replaced then? It would be unbearable to go back to Task Manager from Process Explorer...

Indeed. Besides, I think my scheme would be more elegant.

>I'm saying that, like the example in the root post, you can't give a processes special powers without effectively giving those powers to all processes (which are peers of the special process).

That is false. The IA32 architecture supports that since the nineties or so. The rest is merely a question of design and implementation. I've given a possible scheme in a previous post. I don't know if it's the absolute best way, but I think it's workable.

[While it could be done, making lower-level components aware of higher-level components would also be a violation of general engineering principles. Windows has been working to eradicate these violations not introduce new ones! -Raymond]

re: Why don't we create a special class of programs which can break the normal rules?

Leo Davidson — Sat, 26 Dec 2009 15:27:28 GMT

@Alexander Grigoriev:

I'm not arguing about airtight hatches here; I'm saying that, like the example in the root post, you can't give a processes special powers without effectively giving those powers to all processes (which are peers of the special process).

(In my example, some processes are marked "special" while someone has gone out of their way to prevent other processes from being marked as special, yet those other processes can still become special by manipulating an existing special process.)

So there's little point in giving specific processes special powers via flags/checks which *aren't* an airtight hatch. If you're going to allow one process to bypass certain limits then you might as well allow all processes to do the same and save yourself a lot of needless complexity.

(Another benefit is it makes things smoother for tools which augment or replace the 'special' processes, e.g. Task Manager / Process Explorer or Explorer / other file managers.)

re: Why don't we create a special class of programs which can break the normal rules?

jon — Sat, 26 Dec 2009 10:15:25 GMT

@Alexandor Grigoriev: Since anyone can get through the airtight hatch if they want, what's the point of the hatch being there?

re: Why don't we create a special class of programs which can break the normal rules?

Alexander Grigoriev — Sat, 26 Dec 2009 02:24:44 GMT

@Leo Davidson,

"(Only on Win7 when running as admin under the default UAC settings, though. It's not the end of the world and you can stop it being possible if you modify your configuration.)"

As Raymond likes to say, you're already on another side of an airtight hatch...

re: Why don't we create a special class of programs which can break the normal rules?

Teo — Fri, 25 Dec 2009 19:04:14 GMT

The gory details about self-elevation are irrevelant. My point is that since 2009 vintage Windows *has* special executables that creates special processes. Which proves Raymond wrong.

re: Why don't we create a special class of programs which can break the normal rules?

avek — Fri, 25 Dec 2009 12:26:17 GMT

>couldn't task manager be rewritten inside of win32k.sys?

Oh no!!! How will it be replaced then? It would be unbearable to go back to Task Manager from Process Explorer...

Won't save from mutex problem anyway.

> But imho Explorer.exe is not *a* process, it is the upper layer of the OS

"Upper layer of the OS" is something blurry in any OS influenced by microkernel ideas. Explorer is application-like in many ways. It can be replaced, and sometimes is. It's also a thing that apps can easily mess with.

> It makes sense to implement code-based permissions.

In .NET style? Not very, as Raymond already pointed several times. Stacks within single process can be easily forged by unmanaged code.

Still, it can be done at the level of executable images: CreateProcess, LoadLibrary, etc. become checkable barriers, and the .dll loads/process starts only if the file is both:

- allowed to use for the caller of CreateProcess/LoadLibrary and

- unchanged from the last time when the "allowed" setting was recorded.

If any of the checks fails, user is asked to "allow" the executable/dll to be used again.

There are personal firewalls and security software that do exactly this check. It works because the kernel and kernel-mode drivers can ensure the check, user-mode cannot fake it anymore.

But this scheme alone isn't very useful; those firewalls need to hook additional security-sensitive functions (both in kernel and user mode) to actually protect you. That's because in WinAPI, the functions that need to be secured are not separated into their own .dlls.

I think that's why Windows itself doesn't implement this scheme. Maybe MinWin will change that, but unlikely.

re: Why don't we create a special class of programs which can break the normal rules?

Anonymous Coward — Fri, 25 Dec 2009 11:40:22 GMT

I've thought about the mutex problem for a bit. The only situation where task manager would have to wait for a mutex to become available is where it needs access to a data structure (or similar shared resource) that is currently in an inconsistent state.

Two observations: 1) All other situations can be rewritten without the mutex. 2) Killing the offender makes the situation worse.

Since task manager can be written in such a way that it doesn't share any of its own data structures, it follows that the data structure must be a system data structure (perhaps a structure of the kernel or some other system component; all other data structures that could be forced upon it could be warded off using the task manager's special status). Therefore the mutex should be managed by the system and you can therefore design things in such a way that no process can monopolize it if a process with higher priority needs it.

[The mutexes are indeed designed so no process holds it for very long, but if you suspend the thread while it owns the mutex, it never gets a chace to release it. -Raymond]

re: Why don't we create a special class of programs which can break the normal rules?

Anonymous Coward — Fri, 25 Dec 2009 11:11:43 GMT

One slight nitpick: it is possible to mark processes special in a way that not every process can do. To take the task manager example, you could let the kernel start the Ctrl-Alt-Del process in a special way (i.e. with a function unavailable to user mode code), for example storing a flag in some internal kernel data structure related to the process that enables some functions that other programs can't call. That way, you could give task manager (or ProcessExplorer or some other task manager replacement) extra powers.

Of course that doesn't solve the mutex problem mentioned. At first glance it would appear to be bad design if a program could lock up all processes with higher priority by simply arranging to take a certain mutex, so let's hope that this isn't the case. But if it is, you could let the code that takes the mutex kill whoever's got it if it doesn't give it up within, say, three seconds. That functionality would only be available to special programs of course.

re: Why don't we create a special class of programs which can break the normal rules?

Leo Davidson — Fri, 25 Dec 2009 08:08:39 GMT

@Alexander Grigoriev & @Dan:

Explorer.exe isn't elevated so you can inject into that.

You can then use Explorer's ability to write to protected folders to drop a DLL somewhere which an auto-elevated process will load.

You then run the auto-elevated process. The code in your DLL is now elevated, even though the thing triggering all of this never required elevation.

This isn't just in theory; I've proved it.

(Only on Win7 when running as admin under the default UAC settings, though. It's not the end of the world and you can stop it being possible if you modify your configuration.)