Don't use global state to manage a local problem

re: Don't use global state to manage a local problem

Anonymous Coward — Tue, 16 Dec 2008 09:24:00 GMT

@SuperKoko: your post is too incoherent to be really sure, but I think I have already answered most of your questions in previous posts.

re: Don't use global state to manage a local problem

SuperKoko — Tue, 16 Dec 2008 02:17:32 GMT

> @Mark yourself as an administrative tool, then you

> will have permission to change the time.: I didn't

> say that and I wouldn't be in favour of that.

So, how do you let the third-party administrative tool X which does modify a system setting for a good reason, do it.

Somehow, it has to declare it, which you don't wish, or the user has to get a pop-up.

"Frankly I don't get what people hate about UAC."

UAC is russian roulette.

Assuming there are two kinds of applications:

1) Normal trustable applications. Sometimes, they need high privileges to do their tasks.

e.g. Network clock synchronization requires privileges to set the clock.

Or, a network tool to change the time zone on a whole LAN at a time, require privileges to set the time zone.

2) Worms, malwares, viri...

For applications of kind #1, the "right" answer to UAC is always YES. Clicking NO will (almost) always result in malfunction of the software.

For applications of kind #2, the "right" answer is always NO. This might not always totally stop the malware, but, clicking YES will only makes things worse.

In BOTH cases, a message box convincing the user to click YES can trivially be written. I would even say that it's easier for malwares as they are "free" to tell lie.

So, the message box can be ignore, and the UAC question always comes down to:

Hi, I'm Windows. I'm going to do perform dangerous operation, but I don't know if the program asking for it is evil or not, so, could you tell me:

Are you executing a malware?

When computers have no clue what they're doing, desperate, they ask the user.

(I don't know details, but UAC might also be a problem when managing hundred computers on a LAN and not wanting to click YES hundred times).

Now, we see that there's a third kind of application.

3) Trusted non-malware applications, badly programmed, which modify a global setting to perform an internal calculation.

However, the answer to the UAC should be YES there too, as the application won't work at all if NO is answered, and, surely, the user wants the application to work. So, from a security & user point-of-view kind #3 and kind #1 are the same.

If the declarative model is used, applications of kind #1 and #3 will properly declare that they need these privileges, while, worms will be blocked unless they manage to execute with "installer" privileges (the privileges needed to declare privileges of applications).

This model doesn't help bad developers to fix applications of kind #3.

If the "pop-up" model is used, applications of kind #1 will pop out dialog boxes as part of their normal behavior, and that won't be a bug.

Applications of kind #3 will do the same, and these "pop-ups" won't be reported as bugs during testing.

This model doesn't help bad developers to fix applications of kind #3.

However, this model helps worms to propagate, compared to the other model.

Proper education of *developers* is the only way to fix applications of kind #3.

"There could be other ways to pass to handles to programs"

Which one?

"A common dialog could do the same kind of thing."

ok.

So, a network clock synchronization tool would've to pop up the system clock? Looks weird to me.

What dialog would you show when modifying some obscure registry setting such as obcaseinsensitive, or the user profile folder path?

Would the admin have to close this dialog box on the hundred computers of his LAN?

Give a concrete proposal, with an API and a description of some applications, and I'll read it, but you're being vague enough to make it hard to understand what you're thinking.

re: Don't use global state to manage a local problem

Giuseppe — Mon, 15 Dec 2008 21:53:52 GMT

(back to the topic?)

Sometimes it is difficult for the developer to follow the rule. I have seen many (most of) compression/archieving tools that become "the" global compression/archieving tool (and when one tries to uninstall them, the registry is often messed up, and the native "compressed folder" feature is lost; but this is a bug, of course). The problem is that their GUI are very different. I actually don't know if registering the new application is always a good thing. In my little experience, it is often a source of problems. But I also understand the "marketing": if you sell a "good archiver", you "want" to throw the native one away, right?

re: Don't use global state to manage a local problem

Anonymous Coward — Mon, 15 Dec 2008 21:29:25 GMT

@Mark yourself as an administrative tool, then you will have permission to change the time.: I didn't say that and I wouldn't be in favour of that.

@Thread injection: that opens up a whole 'nother can o' worms, but I think that would take this thread too far off topic.

re: Don't use global state to manage a local problem

Yuhong Bao — Mon, 15 Dec 2008 21:12:06 GMT

[I read it but I don't post to it because I post here. And thanks for taking this thread even further off topic. -Raymond]

Thanks for confirming, because it is hard to tell if you don't post there.

re: Don't use global state to manage a local problem

Yuhong Bao — Mon, 15 Dec 2008 20:53:22 GMT

"Example deleted because it violates the ground rules against identifying a specific company, program, or person. This commenter, despite his/her enthusiasm, tends to violate the ground rules and eventually I will tire of editing the comments and start deleting them."

Well, good thing that there is off-roading the old new thing. BTW, it don't seem to be very active. Raymond: Do you read off-road? Because you don't seem to post in it.

[I read it but I don't post to it because I post here. And thanks for taking this thread even further off topic. -Raymond]

re: Don't use global state to manage a local problem

Anonymous Coward — Mon, 15 Dec 2008 14:41:03 GMT

@Broken applications are broken. Only their developers, or Windows hacks as we see on The old new thing, can fix them.: True, but if broken means that your application doesn't even work in testing, hopefully devs will have some incentive to fix a bug before shipping.

@getting pop-ups they don't understand: Then make them get pop-ups they do understand. Frankly I don't get what people hate about UAC. The only thing I kind of don't like is how the pop up is too generic. The most central item in a good dialog would be what the application is actually trying to do.

(And to add to the above two paragraphs: there are lots of things for which it doesn't make sense to be able to ask the operating system for a privilege. The time zone only needs to be set by the time date applet, which is started by the shell, which will pass the handle on because it knows it's starting the time date applet, or computer setup programs and administration tools, to which you could pass the handle on startup similarly to how we pass command line parameters now. Regardless, either you can change the time zone, or you can't. No way to ask = no pop up.)

[Q: "I need to change the time programmatically in order to perform this internal computation." A: "Mark yourself as an administrative tool, then you will have permission to change the time." Now you're back where you started. Or worse, A: "Inject a thread into Explorer to change the time." Now you have a problem worse than the original problem. -Raymond]

@Anyway, ... tables".: Logical fallacy: false dichotomy. There could be other ways to pass to handles to programs, and if you design the system right, I think that you could get most applications working just right without requiring the user or shell to do anything specific. For example, if you open a document from an Explorer window, Explorer could pass a handle to that document to the application it starts, much like we pass filenames today. A common dialog could do the same kind of thing.

Pure per-application instead of per process has a major deficiency, in that it would be hard to give different instances different access (which you might want sometimes) and to pass handles to running processes. It could be done, but it would be harder and less intuitive.

Backward compatibility could be done using an emulation layer. It would for example interpret a CreateFile( <path> ) as ‘look if there's a handle open in this process that corresponds to path’. It can be done, and it probably wouldn't even be that difficult. You could even pass a handle to a folder to make all files in it accessible.

re: Don't use global state to manage a local problem

SuperKoko — Mon, 15 Dec 2008 12:58:17 GMT

@Anonymous Coward:

A per-application (application being defined by an exe path name + SHA1) access control model would be nice. That would be a generalization of network firewalls to system calls & all other privileges.

However it wouldn't solve the issue of trusted applications changing the global state as part of their internal calculation:

Either applications, when installed, declare the privileges they need, in which case, the application would declare that it sets the time zone, or the user would have to configure that for every application, getting pop-ups they don't understand as UAC does. Even if they manage to understand the pop-up, they'll first click "No" and see that the application doesn't work, so they'll eventually give the privilege the application asks.

Access control can protect against worms & trojans, but cannot automagically repair broken applications. Broken applications are broken. Only their developers, or Windows hacks as we see on The old new thing, can fix them.

Anyway, I don't see how the handle model can be used to implement per-application access control. Either the explorer would pass all the handles to every child process it invokes or it would use an application table to select which handles it must passes to child processes. The latter would be very weak as there're many ways to launch applications without explorer, and every application allowing people to launch other applications would've to use these "firewall tables".

The per-application model used by network firewall is much better IMO.

There's also the argument of backward compatibility. Handles based access control would significantly change the Windows API.

re: Don't use global state to manage a local problem

Anonymous Coward — Mon, 15 Dec 2008 02:56:42 GMT

That is certainly true and it deserves more credit for that than it gets.

However, the shell automatically passes the privilege on to the applications it spawns, which is bad. I want to be able to change the time zone, sure. But only the time and date applet should be able to do this on my behalf, so the shell should only pass the privilege on to that applet, and perhaps others that I explicitly specify.

Also, the access control model is certainly a big improvement over POSIX, but it still leaves a lot to be desired, especially in terms of consistency and default configuration. Some things are controlled by privileges, as the time zone. Other things are controlled by passing handles around (or failing to do so). Yet other things are accessed by pathname which are then on access checked against ACLs which operate by user and group, not by application. The default settings are almost all too permissive.

I think the handle model is the easiest to work with and reason about, as well as the most flexible and the easiest to get watertight, so if we, theoretically speaking, were to adopt one of these models, I'd opt for that one. It also has the nice property that it would be easy (relatively speaking) to add the necessary infrastructure to make it emulate the other two if necessary.

re: Don't use global state to manage a local problem

Yuhong Bao — Sun, 14 Dec 2008 22:15:54 GMT

Another example:

Example deleted because it violates the ground rules against identifying a specific company, program, or person. This commenter, despite his/her enthusiasm, tends to violate the ground rules and eventually I will tire of editing the comments and start deleting them.