InformAction Forums

There are some good sandboxing solutions out there, but none of them are perfect... after a lot of thinking, I've come up with what seems the ideal solution: OS-level sandboxing.

I think privs should be severely limited on an app-by-app basis - each app should only have write access in its own folder (which would take care of a lot of things - app portability, automatic virus limiting, DLL ****) but read access on most folders. (Precisely which folders could be determined by the user)
I realize this could make life really difficult - for example, downloading a file and moving it into another folder - but different permissions levels could help. For example, an app could be granted temporary "write-all" privs, which would let it have write access to other folders.

Memory should also be sandboxed, IMHO - "curtained RAM" would make buffer overflows, etc. a lot harder to execute.



Of course, I'm probably missing some things...

computerfreaker wrote:There are some good sandboxing solutions out there, but none of them are perfect... after a lot of thinking, I've come up with what seems the ideal solution: OS-level sandboxing.

I think privs should be severely limited on an app-by-app basis - each app should only have write access in its own folder (which would take care of a lot of things - app portability, automatic virus limiting, DLL ****) but read access on most folders. (Precisely which folders could be determined by the user)

Won't apps need permission to write to Registry? ... which lets a hacked or malicious app do its damage. And is why Sandboxie creates a virtual Reg hive for the session.

computerfreaker wrote: I realize this could make life really difficult - for example, downloading a file and moving it into another folder - but different permissions levels could help. For example, an app could be granted temporary "write-all" privs, which would let it have write access to other folders.

Probably getting far beyond the average home user, many of whom find merely coping with NoScript to be difficult, judging by both statistics and forum posts. You've got some good idea paths, but it's still sounding IMHO like it's heading toward a virtual machine.

I'm not into Unix, but IIUC, there is far more recognition of the concept of permission levels. If so, then yes, those concepts would be useful in Windows ... with the omnipresent trade-off of security vs. convenience. Probably one reason (among many, not all positive) for MS's success is the sacrifice of security (and a lot of other things, like bloat) for user convenience -- despite the fact that malware causes great inconvenience. Most home users want to take it OOB, fire it up, and go. If you can find a way to combine the two...

As an example of average-userspace, with whom most in the tech community simply can't relate, here are some things that my non-tech friends, who had been using PCs for some years, didn't know:

That you can tile windows on your screen, either vertically or horizontally, with a right-click and a click.
How to get to non-US or non-BR characters to paste into docs and email (Charmap).
How to create your own shortcuts to anything, anywhere you want to, and move the shortcuts, including to the Start menu and/or the Programs menu, and within them.
Etc.

Let's face it: You need to take instruction and get a license before driving a car or flying a plane. In many ways, using a puter is more complex (not physically, but mentally), yet there is no license required, no training for most users older than today's schoolchildren, and the textbook would be an encyclopedia.
Gotta Keep It Simple, but Secure. Agreed, that's very difficult.

computerfreaker wrote: Memory should also be sandboxed, IMHO - "curtained RAM" would make buffer overflows, etc. a lot harder to execute.

IIUC, originally RAM was intended to be "data storage only" and "executable code" areas. But back when memory was very scarce, MS itself took to "borrowing' a little of the data buffers now and then to speed up the execution of an app. The phrase that sticks in my mind (as usual, can't remember the source ) is that they "were using the data buffers as a scratch pad for the executables". ... leading to the hundreds of buffer overrun vulns.

Are you familiar with Data Execution Prevention (DEP), in both hw and sw forms? It essentially does what you're suggesting, and what should have been done in the first place. Had it been in place a decade ago, and on by default instead of mostly off by default, it could have prevented hundreds of varieties, and untold thousands of exploits, during that time. I understand that many modern machines are shipped with it on be default, which is a big step in the right direction.

Keep thinking!

computerfreaker wrote:There are some good sandboxing solutions out there, but none of them are perfect... after a lot of thinking, I've come up with what seems the ideal solution: OS-level sandboxing.

I think privs should be severely limited on an app-by-app basis - each app should only have write access in its own folder (which would take care of a lot of things - app portability, automatic virus limiting, DLL ****) but read access on most folders. (Precisely which folders could be determined by the user)

Tom T. wrote:Won't apps need permission to write to Registry?

No. This would be a heck of a lot of work, but essentially replacing the registry API calls with wrappers that save the prefs in the same folder as the app would fix that little problem.

Here's a demo of what I'm thinking...

* User runs SomeApp.exe
* SomeApp.exe tries to read HKCU\Software\SomeApp\FirstRun to see if it's running for the first time or not
* Registry API's load Prefs.reg from the same folder as SomeApp, load the HKCU\Software\SomeApp\FirstRun preference from within the reg file, and send it back.
* SomeApp.exe tries to write HKCU\Software\SomeApp\ShowStatusbar
* Registry API's saves that preference into Prefs.reg, which is in the same folder as SomeApp

Final file/folder structure:

SomeApp
-----SomeApp.exe
-----Prefs.reg


Of course, it would have to be a bit more involved than that... but that's the general idea.

Tom T. wrote: ... which lets a hacked or malicious app do its damage. And is why Sandboxie creates a virtual Reg hive for the session.

Well, my ideas, when combined, would totally wreck malicious apps.
* Apps only get write access to their own folders
* Registry calls are redirected to make sure this policy stays intact
* RAM is curtained
* Executing an app normally won't give it any way to override these policies, but executing it as admin would. Of course, users would be properly discouraged from always running in admin mode...

computerfreaker wrote: I realize this could make life really difficult - for example, downloading a file and moving it into another folder - but different permissions levels could help. For example, an app could be granted temporary "write-all" privs, which would let it have write access to other folders.

Tom T. wrote:Probably getting far beyond the average home user, many of whom find merely coping with NoScript to be difficult, judging by both statistics and forum posts.

I know, that's the bad part of this.

Tom T. wrote:You've got some good idea paths, but it's still sounding IMHO like it's heading toward a virtual machine.

I'm heading toward something much bigger than that, my friend - I'm thinking of an entirely new OS, written entirely from scratch. (Unless somebody knows how to "hijack" API's in Windows, so the redirect thing can be done)

Tom T. wrote:I'm not into Unix, but IIUC, there is far more recognition of the concept of permission levels. If so, then yes, those concepts would be useful in Windows ... with the omnipresent trade-off of security vs. convenience. Probably one reason (among many, not all positive) for MS's success is the sacrifice of security (and a lot of other things, like bloat) for user convenience -- despite the fact that malware causes great inconvenience. Most home users want to take it OOB, fire it up, and go. If you can find a way to combine the two...

I don't think combining the two will ever happen.
As an analogy, think of a city - if you guard it, it's going to be hard to get in. You'd have to get past constantly-suspicious guards and possibly an automated security system or two. Very inconvenient, but very secure.
On the other hand, if you leave the city totally unguarded, you can get in really quickly - just walk through the gate - but all the bad guys can get in that quickly & easily, too.
Nobody's ever found a way to combine speed & security, AFAIK...

Tom T. wrote:As an example of average-userspace, with whom most in the tech community simply can't relate, here are some things that my non-tech friends, who had been using PCs for some years, didn't know:

That you can tile windows on your screen, either vertically or horizontally, with a right-click and a click.
How to get to non-US or non-BR characters to paste into docs and email (Charmap).
How to create your own shortcuts to anything, anywhere you want to, and move the shortcuts, including to the Start menu and/or the Programs menu, and within them.
Etc.

Wow, that's a somewhat startling list. Then again, these aren't really tech-savvy users so... maybe not so surprising.
Having all kinds of security lockdowns would probably provide lots of headaches for these guys.

Tom T. wrote:Let's face it: You need to take instruction and get a license before driving a car or flying a plane. In many ways, using a puter is more complex (not physically, but mentally), yet there is no license required, no training for most users older than today's schoolchildren, and the textbook would be an encyclopedia.
Gotta Keep It Simple, but Secure. Agreed, that's very difficult.

True. And once again, security is inversely proportional to simplicity. For example, a padlock can easily be broken - but nobody's ever broken into Fort Knox.

computerfreaker wrote: Memory should also be sandboxed, IMHO - "curtained RAM" would make buffer overflows, etc. a lot harder to execute.

Tom T. wrote:IIUC, originally RAM was intended to be "data storage only" and "executable code" areas. But back when memory was very scarce, MS itself took to "borrowing' a little of the data buffers now and then to speed up the execution of an app. The phrase that sticks in my mind (as usual, can't remember the source ) is that they "were using the data buffers as a scratch pad for the executables". ... leading to the hundreds of buffer overrun vulns.

Well, using RAM as a scratch pad isn't that bad an idea - after all, it's a lot faster than using HDD space - but I don't think they really did it properly...

Tom T. wrote:Are you familiar with Data Execution Prevention (DEP), in both hw and sw forms? It essentially does what you're suggesting, and what should have been done in the first place. Had it been in place a decade ago, and on by default instead of mostly off by default, it could have prevented hundreds of varieties, and untold thousands of exploits, during that time. I understand that many modern machines are shipped with it on be default, which is a big step in the right direction.

DEP isn't quite what I'm suggesting. That marks certain areas of RAM as non-executable; my idea is to "curtain" RAM so only the process that allocated it can access it. Of course, DEP would help there too...

Tom T. wrote:Won't apps need permission to write to Registry?

computerfreaker wrote:No. This would be a heck of a lot of work, but essentially replacing the registry API calls with wrappers that save the prefs in the same folder as the app would fix that little problem.

Here's a demo of what I'm thinking...

* User runs SomeApp.exe
* SomeApp.exe tries to read HKCU\Software\SomeApp\FirstRun to see if it's running for the first time or not
* Registry API's load Prefs.reg from the same folder as SomeApp, load the HKCU\Software\SomeApp\FirstRun preference from within the reg file, and send it back.
* SomeApp.exe tries to write HKCU\Software\SomeApp\ShowStatusbar
* Registry API's saves that preference into Prefs.reg, which is in the same folder as SomeApp

Final file/folder structure:

SomeApp
-----SomeApp.exe
-----Prefs.reg

Of course, it would have to be a bit more involved than that... but that's the general idea.

I like your file structure, as that's pretty much like Fx -- minimizes the Windows calls (unlike IE LOL!) and tries to be as self-contained as possible, with its prefs.js, etc. ... What if someone manages to hack prefs.reg into doing something malicious? Or the Registry APIs? (I'm playing Bad Guy here, or "Devi's Advocate", not to bug you , but to throw every possible challenge, to help you develop your plan fully. This is what most devs *don't* do, not just MS, because of the time, expense, and time-pressure to get a release out, but it's the kind of thinking that *must* occur if security is to be baked in rather than added on. )

Wouldn't HKCR come in there somewhere, as the root classes are affected?... but I guess it could be on a read-only basis -- haven't fully thought that out yet.

Tom T. wrote: ... Of course, users would be properly discouraged from always running in admin mode...

Vista's UAC drew a lot of flak, either from annoyed users or from security pros. The former, because of inconvenience; the latter, because after the 100th or so prompt for an admin log-in, users tended just to run as admin all the time, and when faced with prompts at whatever level, there's a tendency to just click "yes" so you can get on with what you're doing. Not arguing with the idea, just that in the Real World of Average Users, it's been difficult to implement any related concept. Most aren't aware of the issue (see the *sample* list below of simple navigational tools that some aren't aware of), and don't want to be bothered. This is a human-factors problem, which are always the most difficult. "The most insecure part of most computers is the user". Amen.

People hate making decisions when it's about something for which they lack the knowledge. Will Mom and Pop, or Grandma and Grandpa, be able to manage the proposed system? *That* is the critical criterion. Again, not discouraging you from brainstorming, just pointing out the things that have to be considered for average (read, "not tech-aware and not interested") users.

Tom T. wrote:You've got some good idea paths, but it's still sounding IMHO like it's heading toward a virtual machine.

computerfreaker wrote:I'm heading toward something much bigger than that, my friend - I'm thinking of an entirely new OS, written entirely from scratch. (Unless somebody knows how to "hijack" API's in Windows, so the redirect thing can be done)

Go for it. When can we expect the first release?

MS has faced this same dilemma: They have much legacy code, but starting from scratch breaks every existing app (your system probably would too); even completely locking down Windows would break a lot of things, especially back-compatibility -- which MS commendably tries to maintain. Probably end up with some kind of emulator, as I understand Win 7 has an XP emulator. Haven't dug into it, but if the emulator is properly isolated, then yeah, I'd buy 7 and run *only* the virtual XP -- that might be a way to go. Still kind of a mini-virtual machine, though. (Remember Grandma and Grandpa!)

Tom T. wrote: ... with the omnipresent trade-off of security vs. convenience. ...

computerfreaker wrote:I don't think combining the two will ever happen.

I was being a bit facetious. It's a standard axiom that complexity and convenience are the opposites of security. The rest of my sentence, "If you can find some way to combine (security and convenience)... was "you'll have achieved what no one else has. " But go for it!

The really basic problem is that the Internet wasn't designed with security in mind, as there was no concept of a "malicious user". Computers were huge, expensive things; the Internet was to interconnect university knowledge bases, government and military units, etc. Who knew that within a few years of its introduction, personal computers would become affordable in many homes? ... also, both Windows and Mac date back to the pre-Internet period, and so weren't designed with that kind of security in mind, a fact which still haunts them. Gates himself admitted that the success of the Internet among home users caught him totally by surprise, and they weren't prepared for it. So we're back to the "from scratch" concept, as above.

Tom T. wrote:As an example of average-userspace, with whom most in the tech community simply can't relate, here are some things that my non-tech friends, who had been using PCs for some years, didn't know:

That you can tile windows on your screen, either vertically or horizontally, with a right-click and a click.
How to get to non-US or non-BR characters to paste into docs and email (Charmap).
How to create your own shortcuts to anything, anywhere you want to, and move the shortcuts, including to the Start menu and/or the Programs menu, and within them.
Etc.

computerfreaker wrote: Wow, that's a somewhat startling list. Then again, these aren't really tech-savvy users so... maybe not so surprising.
Having all kinds of security lockdowns would probably provide lots of headaches for these guys.

These are intelligent people, and that's only the beginning of a very long list. Believe it or not, these are the overwhelming majority of users, and devs cater to that -- or take advantage of it. Hard for those in the tech community to picture this, because they tend to hang with other techies. So yeah, that's your biggest obstacle -- making this locked-down system work for *those* users. Otherwise, it becomes another tiny niche product, like Ubuntu etc.

Not trying to be negative, just trying to show the reality of the situation that has to be dealt with in designing more secure solutions. Sorry if this whole reply so far comes off as negativity -- but the fact that surveys show 80-90% of home puters have some kind of malware proves that most users don't take even the most basic precautions, and don't want to take time to learn them. (Three billion or so SOHO computers in the world, 57 million d/l of NS, many of which are later uninstalled -- do the math.)

computerfreaker wrote: Memory should also be sandboxed, IMHO - "curtained RAM" would make buffer overflows, etc. a lot harder to execute.

Tom T. wrote:IIUC, originally RAM was intended to be "data storage only" and "executable code" areas. But back when memory was very scarce, MS itself took to "borrowing' a little of the data buffers now and then to speed up the execution of an app. The phrase that sticks in my mind (as usual, can't remember the source ) is that they "were using the data buffers as a scratch pad for the executables". ... leading to the hundreds of buffer overrun vulns.

computerfreaker wrote:Well, using RAM as a scratch pad isn't that bad an idea - after all, it's a lot faster than using HDD space - but I don't think they really did it properly...

I'm sorry if I wasn't clear enough. I tend to write too much and too long already , so sometimes condense things too much.

What they did was to use the supposedly *data-only* portions of RAM as a scratch pad for exe's, which *set the precedent* that executable code could be loaded into these supposedly "curtained-off" areas -- a precedent that has caused untold headaches over the years.

Tom T. wrote:Are you familiar with Data Execution Prevention (DEP), in both hw and sw forms? It essentially does what you're suggesting, and what should have been done in the first place. Had it been in place a decade ago, and on by default instead of mostly off by default, it could have prevented hundreds of varieties, and untold thousands of exploits, during that time. I understand that many modern machines are shipped with it on be default, which is a big step in the right direction.

computerfreaker wrote:DEP isn't quite what I'm suggesting. That marks certain areas of RAM as non-executable; my idea is to "curtain" RAM so only the process that allocated it can access it. Of course, DEP would help there too...

Not sure if I'm understanding you correctly, but what if the process that allocated it is malicious code running? ... What DEP deals with is the typical "buffer overrun" where sloppy coding lets bad guy load invalid and/or excessively-long strings, which get loaded into the data buffers. This has been a huge category of attack -- because it's so easy to do; ActiveX has been found to have hundreds of buffer-overflow vulns or "fail to validate input properly".

DEP helps a lot there, and so would your curtain, though apps that have become dependent on MS's bad "scratchpad" precedent would have to be redesigned. DEP has already forced some older apps to update to versions that don't do that.

But I'm still not understanding how the curtain stops the malicious or hacked app, process, malware, etc. in the first place. It's my turn to say I must be missing something.

Keep brainstorming! (but remember Nana! )

Tom T. wrote:Won't apps need permission to write to Registry?

computerfreaker wrote:No. This would be a heck of a lot of work, but essentially replacing the registry API calls with wrappers that save the prefs in the same folder as the app would fix that little problem.

Here's a demo of what I'm thinking...

* User runs SomeApp.exe
* SomeApp.exe tries to read HKCU\Software\SomeApp\FirstRun to see if it's running for the first time or not
* Registry API's load Prefs.reg from the same folder as SomeApp, load the HKCU\Software\SomeApp\FirstRun preference from within the reg file, and send it back.
* SomeApp.exe tries to write HKCU\Software\SomeApp\ShowStatusbar
* Registry API's saves that preference into Prefs.reg, which is in the same folder as SomeApp

Final file/folder structure:

SomeApp
-----SomeApp.exe
-----Prefs.reg

Of course, it would have to be a bit more involved than that... but that's the general idea.

Tom T. wrote:I like your file structure, as that's pretty much like Fx -- minimizes the Windows calls (unlike IE LOL!) and tries to be as self-contained as possible, with its prefs.js, etc. ... What if someone manages to hack prefs.reg into doing something malicious? Or the Registry APIs?

That's the point of my built-in portabilization - even if Prefs.reg does something malicious, the containment will hold it in. It can be as malicious as it likes and only hurt itself... remember, reads/writes redirect to the Prefs.reg file.
There will be no Registry - just a set of wrapper API's that pretend to access it.

The only way anything could happen is if the "registry" API calls are somehow hacked. Not impossible, but should be difficult to do...

Tom T. wrote:(I'm playing Bad Guy here, or "Devi's Advocate", not to bug you , but to throw every possible challenge, to help you develop your plan fully. This is what most devs *don't* do, not just MS, because of the time, expense, and time-pressure to get a release out, but it's the kind of thinking that *must* occur if security is to be baked in rather than added on. )

Thanks, I rather like this!
When people play Devil's Advocate, it generally helps me focus & further define a plan...

Tom T. wrote:Wouldn't HKCR come in there somewhere, as the root classes are affected?... but I guess it could be on a read-only basis -- haven't fully thought that out yet.

Instead of HKCR, how about a database just for file associations? Users would need to run as admin to edit it...

Tom T. wrote: ... Of course, users would be properly discouraged from always running in admin mode...

Tom T. wrote:Vista's UAC drew a lot of flak, either from annoyed users or from security pros. The former, because of inconvenience; the latter, because after the 100th or so prompt for an admin log-in, users tended just to run as admin all the time, and when faced with prompts at whatever level, there's a tendency to just click "yes" so you can get on with what you're doing. Not arguing with the idea, just that in the Real World of Average Users, it's been difficult to implement any related concept. Most aren't aware of the issue (see the *sample* list below of simple navigational tools that some aren't aware of), and don't want to be bothered. This is a human-factors problem, which are always the most difficult. "The most insecure part of most computers is the user". Amen.

yes, security prompts are always problematic. Security vs. convenience again...

Tom T. wrote:People hate making decisions when it's about something for which they lack the knowledge. Will Mom and Pop, or Grandma and Grandpa, be able to manage the proposed system? *That* is the critical criterion. Again, not discouraging you from brainstorming, just pointing out the things that have to be considered for average (read, "not tech-aware and not interested") users.

I know... even a detailed help file on handling security prompts wouldn't be helpful, since decisions have to be made on a program-by-program and action-by-action basis.

Tom T. wrote:You've got some good idea paths, but it's still sounding IMHO like it's heading toward a virtual machine.

computerfreaker wrote:I'm heading toward something much bigger than that, my friend - I'm thinking of an entirely new OS, written entirely from scratch. (Unless somebody knows how to "hijack" API's in Windows, so the redirect thing can be done)

Tom T. wrote:Go for it. When can we expect the first release?

Not for at least several years...
Seriously, I don't have the knowledge I'd need to design any OS - I know a smattering of assembly, but not enough to handle a project like this. And my C++ "skills" amount to writing Hello World... (although I probably could pick up C++ pretty quickly, as I have Java under my belt)
Plus, I don't have the time for it... not yet, anyway. Maybe in a few years...

Tom T. wrote:MS has faced this same dilemma: They have much legacy code, but starting from scratch breaks every existing app (your system probably would too); even completely locking down Windows would break a lot of things, especially back-compatibility -- which MS commendably tries to maintain. Probably end up with some kind of emulator, as I understand Win 7 has an XP emulator. Haven't dug into it, but if the emulator is properly isolated, then yeah, I'd buy 7 and run *only* the virtual XP -- that might be a way to go. Still kind of a mini-virtual machine, though. (Remember Grandma and Grandpa!)

*Sigh*
I think breaking existing apps if necessary should be done - we've reached the point a complete OS re-write is almost preferable to constant virus release/patch release cycles.

Tom T. wrote: ... with the omnipresent trade-off of security vs. convenience. ...

computerfreaker wrote:I don't think combining the two will ever happen.

Tom T. wrote:I was being a bit facetious. It's a standard axiom that complexity and convenience are the opposites of security. The rest of my sentence, "If you can find some way to combine (security and convenience)... was "you'll have achieved what no one else has. " But go for it!

That's almost impossible to go for... a worthy goal, but virtually inaccessible. Unless computers can develop intelligence, real human-like intelligence, that's going to be impossible.

Tom T. wrote:The really basic problem is that the Internet wasn't designed with security in mind, as there was no concept of a "malicious user". Computers were huge, expensive things; the Internet was to interconnect university knowledge bases, government and military units, etc. Who knew that within a few years of its introduction, personal computers would become affordable in many homes? ... also, both Windows and Mac date back to the pre-Internet period, and so weren't designed with that kind of security in mind, a fact which still haunts them. Gates himself admitted that the success of the Internet among home users caught him totally by surprise, and they weren't prepared for it. So we're back to the "from scratch" concept, as above.

yes, Steve Gibson was talking about that in his "broken browser model" podcasts - everything was designed with benign users in mind.
We're almost at the point of scrapping the Internet, the OS's, all applications, and most programming languages, and just starting over.
My favorite quote along these lines: "Spam will no longer be a problem by 2006" - Bill Gates.

Tom T. wrote:As an example of average-userspace, with whom most in the tech community simply can't relate, here are some things that my non-tech friends, who had been using PCs for some years, didn't know:

That you can tile windows on your screen, either vertically or horizontally, with a right-click and a click.
How to get to non-US or non-BR characters to paste into docs and email (Charmap).
How to create your own shortcuts to anything, anywhere you want to, and move the shortcuts, including to the Start menu and/or the Programs menu, and within them.
Etc.

computerfreaker wrote: Wow, that's a somewhat startling list. Then again, these aren't really tech-savvy users so... maybe not so surprising.
Having all kinds of security lockdowns would probably provide lots of headaches for these guys.

Tom T. wrote:These are intelligent people, and that's only the beginning of a very long list. Believe it or not, these are the overwhelming majority of users

I know... "sure, Mom, I'll help you get that program working", and 3 setting-changes later it does. Simple for a tech-oriented guy but not for average users....

Tom T. wrote:and devs cater to that -- or take advantage of it.

Virus & spyware writers take advantage of that too...

Tom T. wrote:Hard for those in the tech community to picture this, because they tend to hang with other techies. So yeah, that's your biggest obstacle -- making this locked-down system work for *those* users. Otherwise, it becomes another tiny niche product, like Ubuntu etc.

I think since security is a niche attribute, a secure OS would probably be a niche OS too...

Tom T. wrote:Not trying to be negative, just trying to show the reality of the situation that has to be dealt with in designing more secure solutions. Sorry if this whole reply so far comes off as negativity -- but the fact that surveys show 80-90% of home puters have some kind of malware proves that most users don't take even the most basic precautions, and don't want to take time to learn them. (Three billion or so SOHO computers in the world, 57 million d/l of NS, many of which are later uninstalled -- do the math.)

Your reply comes off as reality, not negativity...
I know a lot of users don't want to take the time or effort to put precautions in place - I'm having a running battle with some friends to keep NS installed in their Fx's, and I could name a few other security "sins" I happen to know people who commit...

computerfreaker wrote: Memory should also be sandboxed, IMHO - "curtained RAM" would make buffer overflows, etc. a lot harder to execute.

Tom T. wrote:IIUC, originally RAM was intended to be "data storage only" and "executable code" areas. But back when memory was very scarce, MS itself took to "borrowing' a little of the data buffers now and then to speed up the execution of an app. The phrase that sticks in my mind (as usual, can't remember the source ) is that they "were using the data buffers as a scratch pad for the executables". ... leading to the hundreds of buffer overrun vulns.

computerfreaker wrote:Well, using RAM as a scratch pad isn't that bad an idea - after all, it's a lot faster than using HDD space - but I don't think they really did it properly...

Tom T. wrote:I'm sorry if I wasn't clear enough. I tend to write too much and too long already , so sometimes condense things too much.

That's OK, I do that a lot too...

Tom T. wrote:What they did was to use the supposedly *data-only* portions of RAM as a scratch pad for exe's, which *set the precedent* that executable code could be loaded into these supposedly "curtained-off" areas -- a precedent that has caused untold headaches over the years.

Woah. When you said "scratch pad", I was thinking of variables and such - like scratch paper for Math work.

Tom T. wrote:Are you familiar with Data Execution Prevention (DEP), in both hw and sw forms? It essentially does what you're suggesting, and what should have been done in the first place. Had it been in place a decade ago, and on by default instead of mostly off by default, it could have prevented hundreds of varieties, and untold thousands of exploits, during that time. I understand that many modern machines are shipped with it on be default, which is a big step in the right direction.

computerfreaker wrote:DEP isn't quite what I'm suggesting. That marks certain areas of RAM as non-executable; my idea is to "curtain" RAM so only the process that allocated it can access it. Of course, DEP would help there too...

Tom T. wrote:Not sure if I'm understanding you correctly, but what if the process that allocated it is malicious code running?

No problem. The malicious code is curtained into its section of RAM, so it can't overwrite any other RAM. It can't change other apps' files because of the permissions thing, and it can't do anything bad with the Registry because of the transparent API redirects.

Tom T. wrote:What DEP deals with is the typical "buffer overrun" where sloppy coding lets bad guy load invalid and/or excessively-long strings, which get loaded into the data buffers. This has been a huge category of attack -- because it's so easy to do; ActiveX has been found to have hundreds of buffer-overflow vulns or "fail to validate input properly".

I used to use a well-known application that had a buffer-overflow crash on a regular basis - every time it exited, I got the message "This program tried to access memory at xxxxxx. This memory could not be read. Click OK to terminate the program."
I didn't learn what that meant until recently, but it's pretty scary...
Curtained RAM would be incredibly useful here, though. Bad guys wouldn't be able to overwrite other processes' RAM...

Tom T. wrote:DEP helps a lot there, and so would your curtain, though apps that have become dependent on MS's bad "scratchpad" precedent would have to be redesigned. DEP has already forced some older apps to update to versions that don't do that.

Well, apps that are dependent on MS's scratchpad precedent should be redone anyway...

Tom T. wrote:But I'm still not understanding how the curtain stops the malicious or hacked app, process, malware, etc. in the first place. It's my turn to say I must be missing something.

Curtained RAM won't stop malicious apps from running - it would stop malicious apps from accessing other processes' RAM. That would prevent buffer overflows, etc... added to the file-system security lockdown, that should make the OS pretty darn safe IMHO.

Tom T. wrote:Wouldn't HKCR come in there somewhere, as the root classes are affected?... but I guess it could be on a read-only basis -- haven't fully thought that out yet.

computerfreaker wrote:Instead of HKCR, how about a database just for file associations? Users would need to run as admin to edit it...

We get back to this same thing of most users tending to run as admin anyway, at least after the 100th prompt. Presumably, most wouldn't have a need to edit the root classes, but you can edit file associations directly through the Windows GUI, which I sometimes do .... so here is our user logging in as admin again.

And of course, you need bullet-proof protection against privilege-escalation attacks.

Is installation of new sw to be allowed by admins only? Here we go again... and if the new sw is hacked or malicious by design... and you have to run as admin to install it....

computerfreaker wrote: I know... even a detailed help file on handling security prompts wouldn't be helpful, since decisions have to be made on a program-by-program and action-by-action basis.

Mostly, it wouldn't be helpful because very few users would read it. Observe our previous discussions about how many people, selves included, read all of a program's User Guide and FAQ before firing it up for the first time. We expect and like intuitiveness.

AUs (average, majority users -- new acronym here, also the symbol for gold ) don't have time to read everything about their OS and every app on it and every feature of it and every safety precaution, and studies in corporate environments show that even people who've attended classes on securing their workstations tend to violate the rules if they're inconvenient to follow (e. g., frequent password changes, strong, non-memorizable pws, never use the same pw twice, don't put it on a sticky on the bottom of the keyboard, etc.)

Tom T. wrote:MS has faced this same dilemma: They have much legacy code, but starting from scratch breaks every existing app (your system probably would too); even completely locking down Windows would break a lot of things, especially back-compatibility -- which MS commendably tries to maintain. Probably end up with some kind of emulator, as I understand Win 7 has an XP emulator. Haven't dug into it, but if the emulator is properly isolated, then yeah, I'd buy 7 and run *only* the virtual XP -- that might be a way to go. Still kind of a mini-virtual machine, though. (Remember Grandma and Grandpa!)

computerfreaker wrote:*Sigh* ... I think breaking existing apps if necessary should be done - we've reached the point a complete OS re-write is almost preferable to constant virus release/patch release cycles.

In the long run, agree. But how to transition? Your system probably won't be compatible with the existing Internet, which we agree needs to be re-designed anyway, so there would have to be a (rather painful) period where there are two Internets, with an air-tight way for one to talk to the other; or else, at midnight UTC on Dec.31, 2015, the entire Internet shuts down while the hw and sw for the new system are activated, and everyone then uses their new OS vs. the existing one on their dual-boot HD, and uses the new compatible versions of their apps vs. the old ones (I see the third-party sw and hw vendors getting rich here ). Plus you have tons of people who haven't even learned how to use Windows thoroughly or safely (see the comments on that). The whole world has to learn your new system.

I expect many Mac users are more tech-savvy, though I have two sets of elderly neighbors who bought Macs for the reputation and beauty, and don't know a thing about what goes on under the hood. Example: One moved into this multi-family building recently. We met; they had a Mac, and among other topics, I asked if they were set up OK with Net service. The woman said that at the moment, she was on Network X. I told her that (wireless) Network X was unsecured, as so many wireless networks *still* are, and that therefore, her traffic could be read by any sniffer driving by or in the vicinity. (I had once left a note on the door of the owner of Network X, saying that my laptop was picking up their unsecured network, and that while I was certainly not the type to take advantage of that, anyone else could, so I would be happy to show them how to secure it. No reply, ever.) So I gave this nice elderly couple the key to my WPA2 wireless LAN pending getting their own ISP and router, which again I told them I would help them to secure. But without that intervention, I expect they'd have blissfully (and illegally, actually) continued to piggyback on the other network forever. I think they thought it was a free service of the building.

This is very typical of what you are dealing with. Not just in regards to OS, but in regards to level of tech and security knowledge of AUs: Near zero.

Your ideal system would have to be completely secure without any user intervention, configuration, add-ons, decisions, right OOB. If you can do that, your place in the history of computing is assured.

computerfreaker wrote:That's almost impossible to go for... a worthy goal, but virtually inaccessible. Unless computers can develop intelligence, real human-like intelligence, that's going to be impossible.

Yup. But the difficult, you do immediately; the impossible takes a little longer. You know, they said man could never fly -- heavier-than-air flight was "impossible"... (changing from negativity to encouragement here, didja' catch that? )

computerfreaker wrote:My favorite quote along these lines: "Spam will no longer be a problem by 2006" - Bill Gates.

My fave Gates quote: At the introduction of XP: "XP will be our safest operating system ever." Three years and two service packs later, they got it to where a reasonably-bright nine-year-old could no longer hack it in less than fifteen minutes.

Side note: He never did say, "640k (RAM) should be enough for anyone." What he said in retrospect was that at the time, they thought that the jump to 640k would give them ten years or so, and they were surprised when five or six years later, third-party devs were clamoring for more RAM, because of all the neat things they could do if they had it. (Tom's Corollary to Parkinson's Law: "Apps bloat to fill the available resources.")

Tom T. wrote:As an example of average-userspace, with whom most in the tech community simply can't relate, here are some things that my non-tech friends, who had been using PCs for some years, didn't know:

That you can tile windows on your screen, either vertically or horizontally, with a right-click and a click.
How to get to non-US or non-BR characters to paste into docs and email (Charmap).
How to create your own shortcuts to anything, anywhere you want to, and move the shortcuts, including to the Start menu and/or the Programs menu, and within them.
Etc.

computerfreaker wrote: Wow, that's a somewhat startling list. Then again, these aren't really tech-savvy users so... maybe not so surprising.
Having all kinds of security lockdowns would probably provide lots of headaches for these guys.

Tom T. wrote:These are intelligent people, and that's only the beginning of a very long list. Believe it or not, these are the overwhelming majority of users

computerfreaker wrote: I know... "sure, Mom, I'll help you get that program working", and 3 setting-changes later it does. Simple for a tech-oriented guy but not for average users....

Or those who don't have a high-tech family member... or Mom or Grandma lives 1000 miles away. Time for a remote-administration product (not MS Remote Desktop, *pleeze*! ) But again, if there's no one in the family or friend circle....

Tom T. wrote:Hard for those in the tech community to picture this, because they tend to hang with other techies. So yeah, that's your biggest obstacle -- making this locked-down system work for *those* users. Otherwise, it becomes another tiny niche product, like Ubuntu etc.

computerfreaker wrote: I think since security is a niche attribute, a secure OS would probably be a niche OS too...

Now we're back to compatibility issues and emulators. What percent of apps that run on Windows will run on *nix without an emulator? And we've no longer solved the problem of global insecurity. You and I are doing all we can for ourselves, but about those other 98%, most of whose machines are already infected...

computerfreaker wrote:I know a lot of users don't want to take the time or effort to put precautions in place - I'm having a running battle with some friends to keep NS installed in their Fx's, and I could name a few other security "sins" I happen to know people who commit...

I rest my case.

It's got to be totally secure OOB, with all of the security mechanisms invisible to the user, running flawlessly. (Can you say, "Nobel Prize"? )

Tom T. wrote:What they did was to use the supposedly *data-only* portions of RAM as a scratch pad for exe's, which *set the precedent* that executable code could be loaded into these supposedly "curtained-off" areas -- a precedent that has caused untold headaches over the years.

computerfreaker wrote:Woah. When you said "scratch pad", I was thinking of variables and such - like scratch paper for Math work.

Sorry -- again unclear on my part. More accurate: The exe's were allowed to borrow parts of the supposed "data-only" curtained area for their process execution, so that the app would execute faster.

Tom T. wrote:Not sure if I'm understanding you correctly, but what if the process that allocated it is malicious code running?

computerfreaker wrote:No problem. The malicious code is curtained into its section of RAM, so it can't overwrite any other RAM. It can't change other apps' files because of the permissions thing, and it can't do anything bad with the Registry because of the transparent API redirects.

If we accept for the moment that you've achieved all that, recall the long thread (I'd rather not link it) from the user who challenged whether default-deny JS was necessary for good security. (His wife didn't want to be bothered with NS. I rest my case yet again. ) Giorgio showed him how malcode could execute "within the browser processes itself", including obtaining your stored pws and much other malice. And he pointed out that *no* firewall, AV, or anything else is going to tag the browser process as malware.

What I'm beginning to see is super-heueristics -- which is what you were getting to with AI. An OS that doesn't look for *signatures* of viruses, but at "behavior". But it's so hard to distinguish -- you'd have to be able to differentiate something the user wants to do with something that malicious code wants to do. And you need users to have *some* permissions, yet they have to know what they're doing, or they could hose your system, or worse, *its safety measures".

It's like cars: We required seat belts and shoulder harnesses, air bags, dual anti-lock brakes, non-shatter windshields, etc. Yet that doesn't stop some drunk from crossing the middle of the road, or some speed demon from going too fast around a curve, etc. It's *mitigated* the damage -- the death toll is lower in real numbers than it was 30-40 years ago, IIRC, and even lower in percentages (since the population is much higher than it was then). But still, 40,000 traffic deaths per year in the US.

IOW, can you truly make anything idiot-proof?
"Make it idiot-proof, and someone will make a better idiot".
"A common mistake that people make when trying to design something completely foolproof was to underestimate the ingenuity of complete fools."
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

computerfreaker wrote: I used to use a well-known application that had a buffer-overflow crash on a regular basis - every time it exited, I got the message "This program tried to access memory at xxxxxx. This memory could not be read. Click OK to terminate the program."
I didn't learn what that meant until recently, but it's pretty scary...

Uh-oh. I get that *randomly* at *shut-down only*, but assumed that it was due to the severe (90%) trimming of Windows and many apps -- something was trying to find something that I deleted as being unnecessary *for my needs*. Could you elaborate, either here, in PM, or in email, please? ... especially use private communications if you don't want to name the app for fear of them jumping on you. TIA.

computerfreaker wrote:Curtained RAM would be incredibly useful here, though. Bad guys wouldn't be able to overwrite other processes' RAM...

I see the concept of a big help, but see again the example of the browser.

Tom T. wrote:DEP helps a lot there, and so would your curtain, though apps that have become dependent on MS's bad "scratchpad" precedent would have to be redesigned. DEP has already forced some older apps to update to versions that don't do that.

computerfreaker wrote:Well, apps that are dependent on MS's scratchpad precedent should be redone anyway...

Absolutely, and most have, now that DEP has been on by default for many machines for a couple of years or so now. Now, all you have to do is get all the devs to validate all inputs properly against design parameters... we talked about this once. Read November's Patch Tuesday KBs -- the tech ones, not the home user version. "A remote execution vuln has been found in X. <snip> X does not properly validate inputs.... " etc. ad infinitum for years.

Same with web sites, btw.

Your life's work is laid out four you! (seriously, interesting and thought-provoking discussion. )

Tom T. wrote:Wouldn't HKCR come in there somewhere, as the root classes are affected?... but I guess it could be on a read-only basis -- haven't fully thought that out yet.

computerfreaker wrote:Instead of HKCR, how about a database just for file associations? Users would need to run as admin to edit it...

Tom T. wrote:We get back to this same thing of most users tending to run as admin anyway, at least after the 100th prompt.

Yeah. Always a problem...
Another possibility is to have the computer generate a random passcode on startup and require the user to enter the passcode to do any admin-level things... only problems are, #1 it's pretty darn inconvenient and #2 we're back to users entering the passcode without even thinking about it.

Tom T. wrote:Presumably, most wouldn't have a need to edit the root classes, but you can edit file associations directly through the Windows GUI, which I sometimes do .... so here is our user logging in as admin again.

I know...

Tom T. wrote:And of course, you need bullet-proof protection against privilege-escalation attacks.

Yeah, that's a critical part of things. Easy to talk about blocking escalation attacks but almost impossible to actually do effectively...

Tom T. wrote:Is installation of new sw to be allowed by admins only? Here we go again... and if the new sw is hacked or malicious by design... and you have to run as admin to install it....

No, installation would be allowed by any user. The built-in sandboxing would protect users from malicious apps... (until the malicious app tries to do something that needs admin rights, the user mindlessly logs in as admin and allows it, and the whole thing goes to pot)

computerfreaker wrote: I know... even a detailed help file on handling security prompts wouldn't be helpful, since decisions have to be made on a program-by-program and action-by-action basis.

Tom T. wrote:Mostly, it wouldn't be helpful because very few users would read it. Observe our previous discussions about how many people, selves included, read all of a program's User Guide and FAQ before firing it up for the first time. We expect and like intuitiveness.

True. I was thinking more of a link included in the prompt - something like "Program X is trying to perform action Y. You shouldn't allow this action unless you trust this program. To learn more, click here" - here is a link to the security-prompt help file. Once again, though, users will probably ignore it and login as admin... "the most vulnerable software is the software between the ears"

Tom T. wrote:AUs (average, majority users -- new acronym here, also the symbol for gold ) don't have time to read everything about their OS and every app on it and every feature of it and every safety precaution, and studies in corporate environments show that even people who've attended classes on securing their workstations tend to violate the rules if they're inconvenient to follow (e. g., frequent password changes, strong, non-memorizable pws, never use the same pw twice, don't put it on a sticky on the bottom of the keyboard, etc.)

AUs probably don't understand a lot of security features anyway... it wasn't until recently I learned about SQL injection attacks, and it took a little while for me to comprehend the concept, even with a WP article to help me out. An AU would probably have a lot more trouble... and that's not even that advanced a concept.

Tom T. wrote:MS has faced this same dilemma: They have much legacy code, but starting from scratch breaks every existing app (your system probably would too); even completely locking down Windows would break a lot of things, especially back-compatibility -- which MS commendably tries to maintain. Probably end up with some kind of emulator, as I understand Win 7 has an XP emulator. Haven't dug into it, but if the emulator is properly isolated, then yeah, I'd buy 7 and run *only* the virtual XP -- that might be a way to go. Still kind of a mini-virtual machine, though. (Remember Grandma and Grandpa!)

computerfreaker wrote:*Sigh* ... I think breaking existing apps if necessary should be done - we've reached the point a complete OS re-write is almost preferable to constant virus release/patch release cycles.

Tom T. wrote:In the long run, agree. But how to transition? Your system probably won't be compatible with the existing Internet

It would have to be. The existing Internet isn't going anywhere anytime soon, IMHO...

Here's where the sandbox idea begins to fall apart, because things like the malicious innoshots addon would take full advantage of the browser's privs - and sandboxing wouldn't prevent the infection.

Tom T. wrote:which we agree needs to be re-designed anyway, so there would have to be a (rather painful) period where there are two Internets, with an air-tight way for one to talk to the other

Oh man, that can & will get hairy fast... and even a single XSS or CSRF attack could breach the passageway between the Internets and wreck everything. You can bet your life the black-hats will be spending all their time working on breaking the air-tight seal, too...

Tom T. wrote:or else, at midnight UTC on Dec.31, 2015, the entire Internet shuts down while the hw and sw for the new system are activated, and everyone then uses their new OS vs. the existing one on their dual-boot HD, and uses the new compatible versions of their apps vs. the old ones (I see the third-party sw and hw vendors getting rich here ). Plus you have tons of people who haven't even learned how to use Windows thoroughly or safely (see the comments on that). The whole world has to learn your new system.

That's pretty painful, too. First, as always, we'll have people who can't/won't upgrade - they'll stick with their old h/w and s/w for whatever reason. (And what about discontinued apps that people rely on? For example, the CS Lite Firefox addon - it's discontinued, but lots of people, myself included, still use & like it. Upgrade the systems and CS Lite users get to make a hard choice... and that's just a single app out of the gazillions out there)
Next, if there's even a single problem with the h/w or s/w, there's going to be a circus during the upgrade process. Windows 7, for example, caused a lot of people upgrade problems - if this OS has any similar issues, people are going to have some serious problems.
Finally, that leaves all the people who can't/won't learn a new OS out in the cold... and that's an awful lot of people.

Tom T. wrote:I expect many Mac users are more tech-savvy

I'm not so sure about that... (no offense to Mac users)
People think Macs are more secure from malware, but that's not true... this could be a similar thing. (idk though...)

Tom T. wrote:though I have two sets of elderly neighbors who bought Macs for the reputation and beauty, and don't know a thing about what goes on under the hood. Example: One moved into this multi-family building recently. We met; they had a Mac, and among other topics, I asked if they were set up OK with Net service. The woman said that at the moment, she was on Network X. I told her that (wireless) Network X was unsecured, as so many wireless networks *still* are, and that therefore, her traffic could be read by any sniffer driving by or in the vicinity. (I had once left a note on the door of the owner of Network X, saying that my laptop was picking up their unsecured network, and that while I was certainly not the type to take advantage of that, anyone else could, so I would be happy to show them how to secure it. No reply, ever.) So I gave this nice elderly couple the key to my WPA2 wireless LAN pending getting their own ISP and router, which again I told them I would help them to secure. But without that intervention, I expect they'd have blissfully (and illegally, actually) continued to piggyback on the other network forever. I think they thought it was a free service of the building.

That's the kind of story that ends up on The Daily WTF... like this one, for example. http://thedailywtf.com/Articles/Choose-Your-Own-IP.aspx
Part of me wants to laugh and part of me wants to cry when I read things like this...

Tom T. wrote:This is very typical of what you are dealing with. Not just in regards to OS, but in regards to level of tech and security knowledge of AUs: Near zero.

I'm pretty aware of this... (in my programming class, I recently helped someone who didn't even know what browser they were using, or what a browser was - nice guy, but not very tech-savvy)

Tom T. wrote:Your ideal system would have to be completely secure without any user intervention, configuration, add-ons, decisions, right OOB. If you can do that, your place in the history of computing is assured.

I think computers might need AI for that kind of job...

computerfreaker wrote:That's almost impossible to go for... a worthy goal, but virtually inaccessible. Unless computers can develop intelligence, real human-like intelligence, that's going to be impossible.

Tom T. wrote:Yup. But the difficult, you do immediately; the impossible takes a little longer. You know, they said man could never fly -- heavier-than-air flight was "impossible"... (changing from negativity to encouragement here, didja' catch that? )

I've heard a nice quote along those lines - "It's a well-known scientific fact that bees can't fly. Their bodies are too large and their wings too small. However, bees don't read scientific papers - they just fly around"

computerfreaker wrote:My favorite quote along these lines: "Spam will no longer be a problem by 2006" - Bill Gates.

Tom T. wrote:My fave Gates quote: At the introduction of XP: "XP will be our safest operating system ever." Three years and two service packs later, they got it to where a reasonably-bright nine-year-old could no longer hack it in less than fifteen minutes.

At least XP's better than Vista or 7...

Tom T. wrote:Side note: He never did say, "640k (RAM) should be enough for anyone." What he said in retrospect was that at the time, they thought that the jump to 640k would give them ten years or so, and they were surprised when five or six years later, third-party devs were clamoring for more RAM, because of all the neat things they could do if they had it. (Tom's Corollary to Parkinson's Law: "Apps bloat to fill the available resources.")

640k of RAM... and today, 2 GB is generally reckoned to be too little.
computerfreaker's Corollary to Parkinson's Law: "As hardware gets more powerful, software gets more resource-intensive to use the extra power"

Tom T. wrote:As an example of average-userspace, with whom most in the tech community simply can't relate, here are some things that my non-tech friends, who had been using PCs for some years, didn't know:

That you can tile windows on your screen, either vertically or horizontally, with a right-click and a click.
How to get to non-US or non-BR characters to paste into docs and email (Charmap).
How to create your own shortcuts to anything, anywhere you want to, and move the shortcuts, including to the Start menu and/or the Programs menu, and within them.
Etc.

computerfreaker wrote: Wow, that's a somewhat startling list. Then again, these aren't really tech-savvy users so... maybe not so surprising.
Having all kinds of security lockdowns would probably provide lots of headaches for these guys.

Tom T. wrote:These are intelligent people, and that's only the beginning of a very long list. Believe it or not, these are the overwhelming majority of users

computerfreaker wrote: I know... "sure, Mom, I'll help you get that program working", and 3 setting-changes later it does. Simple for a tech-oriented guy but not for average users....

Tom T. wrote:Or those who don't have a high-tech family member... or Mom or Grandma lives 1000 miles away. Time for a remote-administration product (not MS Remote Desktop, *pleeze*! ) But again, if there's no one in the family or friend circle....

I've heard good things about TeamViewer and 2X, both freeware apps for remote-administration... but you're right, if there's nobody in the family/friend circle Mom or Grandma is probably out of luck.

Tom T. wrote:Hard for those in the tech community to picture this, because they tend to hang with other techies. So yeah, that's your biggest obstacle -- making this locked-down system work for *those* users. Otherwise, it becomes another tiny niche product, like Ubuntu etc.

computerfreaker wrote: I think since security is a niche attribute, a secure OS would probably be a niche OS too...

Tom T. wrote:Now we're back to compatibility issues and emulators. What percent of apps that run on Windows will run on *nix without an emulator?

Close to 0%.
Wine wasn't created because people were bored...

Tom T. wrote:And we've no longer solved the problem of global insecurity.

True. Security's clashing with ease-of-use again, and nobody's winning...

Tom T. wrote:You and I are doing all we can for ourselves, but about those other 98%, most of whose machines are already infected...

I know...

computerfreaker wrote:I know a lot of users don't want to take the time or effort to put precautions in place - I'm having a running battle with some friends to keep NS installed in their Fx's, and I could name a few other security "sins" I happen to know people who commit...

Tom T. wrote:I rest my case.

It's got to be totally secure OOB, with all of the security mechanisms invisible to the user, running flawlessly. (Can you say, "Nobel Prize"? )

Can you say "total redesign of everything"?

Tom T. wrote:What they did was to use the supposedly *data-only* portions of RAM as a scratch pad for exe's, which *set the precedent* that executable code could be loaded into these supposedly "curtained-off" areas -- a precedent that has caused untold headaches over the years.

computerfreaker wrote:Woah. When you said "scratch pad", I was thinking of variables and such - like scratch paper for Math work.

Tom T. wrote:Sorry -- again unclear on my part. More accurate: The exe's were allowed to borrow parts of the supposed "data-only" curtained area for their process execution, so that the app would execute faster.

I actually understood you the second time, I was referring to your first explanation...
Thanks for the clarification though!

Tom T. wrote:Not sure if I'm understanding you correctly, but what if the process that allocated it is malicious code running?

computerfreaker wrote:No problem. The malicious code is curtained into its section of RAM, so it can't overwrite any other RAM. It can't change other apps' files because of the permissions thing, and it can't do anything bad with the Registry because of the transparent API redirects.

Tom T. wrote:If we accept for the moment that you've achieved all that, recall the long thread (I'd rather not link it) from the user who challenged whether default-deny JS was necessary for good security. (His wife didn't want to be bothered with NS. I rest my case yet again. )

I recall that thread... not too pretty.

Tom T. wrote:Giorgio showed him how malcode could execute "within the browser processes itself", including obtaining your stored pws and much other malice. And he pointed out that *no* firewall, AV, or anything else is going to tag the browser process as malware.

And my sandboxing idea is helpless too, since the malcode would stay in the same folder as the browser and do its work from there.

Tom T. wrote:What I'm beginning to see is super-heueristics -- which is what you were getting to with AI. An OS that doesn't look for *signatures* of viruses, but at "behavior".

Yep, that's what I was getting to with AI... but it's going to have to be almost human. For example, most Fx addons are legit - but it took humans to look at the innoshots code and recognize it as malware. Then the AV apps jumped on board, but those same AV apps flag a lot of legit apps - especially those made with AutoHotKey and AutoIT - as malware. It's going to take AI to handle a problem this size...

Tom T. wrote:But it's so hard to distinguish -- you'd have to be able to differentiate something the user wants to do with something that malicious code wants to do.

I know. And the line gets fuzzier - some users install keyloggers to keep an eye on their system and who's doing what with it, but a lot of malware installs keyloggers too. How can the OS tell them apart if even a human can't?

Tom T. wrote:And you need users to have *some* permissions, yet they have to know what they're doing, or they could hose your system, or worse, *its safety measures".

It's like cars: We required seat belts and shoulder harnesses, air bags, dual anti-lock brakes, non-shatter windshields, etc. Yet that doesn't stop some drunk from crossing the middle of the road, or some speed demon from going too fast around a curve, etc. It's *mitigated* the damage -- the death toll is lower in real numbers than it was 30-40 years ago, IIRC, and even lower in percentages (since the population is much higher than it was then). But still, 40,000 traffic deaths per year in the US.

Well, I think even lowering the infection rate would be good... taking it from 98% down to even 40% would be huge.

Tom T. wrote:IOW, can you truly make anything idiot-proof?

um, probably not...

Tom T. wrote:"Make it idiot-proof, and someone will make a better idiot".
"A common mistake that people make when trying to design something completely foolproof was to underestimate the ingenuity of complete fools."
"Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning."

So true, but so sad... (reminds me of The Daily WTF story about a Board of Directors member who looked at a support ticket upside down and read 3 as E - http://thedailywtf.com/Articles/1285E8- ... pport.aspx)

computerfreaker wrote: I used to use a well-known application that had a buffer-overflow crash on a regular basis - every time it exited, I got the message "This program tried to access memory at xxxxxx. This memory could not be read. Click OK to terminate the program."
I didn't learn what that meant until recently, but it's pretty scary...

Tom T. wrote:Uh-oh. I get that *randomly* at *shut-down only*, but assumed that it was due to the severe (90%) trimming of Windows and many apps -- something was trying to find something that I deleted as being unnecessary *for my needs*. Could you elaborate, either here, in PM, or in email, please? ... especially use private communications if you don't want to name the app for fear of them jumping on you. TIA.

Sure, let me drop you a PM. Under no circumstances will I put this out publicly... (I will say, though, that #1 the crash was persistent - every time I closed the app - and #2 the problem seems to have been fixed)

computerfreaker wrote:Curtained RAM would be incredibly useful here, though. Bad guys wouldn't be able to overwrite other processes' RAM...

Tom T. wrote:I see the concept of a big help, but see again the example of the browser.

yes, malware would be able to piggyback on the browser... at least the malware couldn't harm any other process.

Tom T. wrote:DEP helps a lot there, and so would your curtain, though apps that have become dependent on MS's bad "scratchpad" precedent would have to be redesigned. DEP has already forced some older apps to update to versions that don't do that.

computerfreaker wrote:Well, apps that are dependent on MS's scratchpad precedent should be redone anyway...

Tom T. wrote:Absolutely, and most have, now that DEP has been on by default for many machines for a couple of years or so now. Now, all you have to do is get all the devs to validate all inputs properly against design parameters... we talked about this once. Read November's Patch Tuesday KBs -- the tech ones, not the home user version. "A remote execution vuln has been found in X. <snip> X does not properly validate inputs.... " etc. ad infinitum for years.

Even one poorly-done app can wreck the well-designed apps - that's what sandboxing is for: to minimize the damage a poorly-written app can cause.

Tom T. wrote:Same with web sites, btw.

yes, XSS and CSRF attacks are getting disturbingly popular...

Tom T. wrote:Your life's work is laid out four you! (seriously, interesting and thought-provoking discussion. )

yes, this has been a very interesting discussion... thanks for all the input!

Just a few short comments, so that you can get back to your Nobel-Prize-winning complete redesign of everything.

computerfreaker wrote:Here's where the sandbox idea begins to fall apart, because things like the malicious innoshots addon would take full advantage of the browser's privs - and sandboxing wouldn't prevent the infection.

Right, that's one example of what I was thinking of when I referred to a hacked or malicious app. A browser extension, that runs as part of the browser process, is a perfect example of that.

computerfreaker wrote:(And what about discontinued apps that people rely on?....

You mean, like using Adblock (original) vs. AB+?

You'll note at the bottom that I'm using Fx 3.5.5 instead of my default Fx.2-20 for this post -- figured I'd better.....

computerfreaker wrote:(in my programming class, I recently helped someone who didn't even know what browser they were using, or what a browser was - nice guy, but not very tech-savvy)

Uh, pardon my denseness, but what is he doing in a *programming* class if he doesn't yet know what a browser is?

computerfreaker wrote:I've heard a nice quote along those lines - "It's a well-known scientific fact that bees can't fly. Their bodies are too large and their wings too small. However, bees don't read scientific papers - they just fly around"

IIRC, the advent of ultra-high-speed cameras enabled aerodynamics experts to observe that the bees weren't just flapping their wings, but rather making various tiny motions with them that increased lift -- sort of like your B-767 extending slats and flaps for take-off. Until then, they really didn't know how to square the discrepancy.... just a bit of trivia.

computerfreaker wrote:computerfreaker's Corollary to Parkinson's Law: "As hardware gets more powerful, software gets more resource-intensive to use the extra power"

Um.... I *think* that's what I I said -- in less technical terms.

(remote admin for low-tech family member)

computerfreaker wrote: I've heard good things about TeamViewer and 2X, both freeware apps for remote-administration..

I used two paid apps, but they needed to be installed correctly on Gramp's machine, and you can't install it remotely until you install it, if you know what I mean... fortunately, there was a family friend nearby who followed my detailed instruction sheet (call me on a hardline, landline phone to arrange a pre-shared key ) and got the server installed for Gramps, after which we were good. But if there hadn't been, it would have had to have waited for my next visit, and the distance wasn't trivial. But if I hadn't been in the family in the first place, Gramps would have been out of luck...

Tom T. wrote: If we accept for the moment that you've achieved all that, recall the long thread (I'd rather not link it) from the user who challenged whether default-deny JS was necessary for good security. (His wife didn't want to be bothered with NS. I rest my case yet again. )

computerfreaker wrote:I recall that thread... not too pretty.

Here''s another that just came up (they do every once in a while, fairly regularly. And these are only the ones who bother to post.): http://forums.informaction.com/viewtopi ... 632#p13617

You'll note that another Mod *did* link the thread in question, yet OP still said that NS script-blocking wasn't necessary. There is none so blind as he who will not see....

Actually, that sums up the whole problem in a nutshell... but keep brainstorming!

computerfreaker wrote:Here's where the sandbox idea begins to fall apart, because things like the malicious innoshots addon would take full advantage of the browser's privs - and sandboxing wouldn't prevent the infection.

Tom T. wrote:Right, that's one example of what I was thinking of when I referred to a hacked or malicious app. A browser extension, that runs as part of the browser process, is a perfect example of that.

yeah, how many times have we seen malicious IE addons, toolbars, and whatnot? Sandboxing wouldn't work there, curtained RAM wouldn't work there, and nothing would stop it except maybe an AV or a user who notices something wrong (like Montagar in that still-going innoshots thread)

computerfreaker wrote:(And what about discontinued apps that people rely on?....

Tom T. wrote:You mean, like using Adblock (original) vs. AB+?

Something like that...

Tom T. wrote:You'll note at the bottom that I'm using Fx 3.5.5 instead of my default Fx.2-20 for this post -- figured I'd better.....

computerfreaker wrote:(in my programming class, I recently helped someone who didn't even know what browser they were using, or what a browser was - nice guy, but not very tech-savvy)

Tom T. wrote:Uh, pardon my denseness, but what is he doing in a *programming* class if he doesn't yet know what a browser is?

Please don't ask me, I have no idea. I did have the same reaction as you, though...

computerfreaker wrote:I've heard a nice quote along those lines - "It's a well-known scientific fact that bees can't fly. Their bodies are too large and their wings too small. However, bees don't read scientific papers - they just fly around"

Tom T. wrote:IIRC, the advent of ultra-high-speed cameras enabled aerodynamics experts to observe that the bees weren't just flapping their wings, but rather making various tiny motions with them that increased lift -- sort of like your B-767 extending slats and flaps for take-off. Until then, they really didn't know how to square the discrepancy.... just a bit of trivia.

Interesting!
The point of the quote is still the same though: don't believe everything you see, hear or read.

computerfreaker wrote:computerfreaker's Corollary to Parkinson's Law: "As hardware gets more powerful, software gets more resource-intensive to use the extra power"

Tom T. wrote:Um.... I *think* that's what I I said -- in less technical terms.

Um, yes. I just like the extra tech-speak in there... (oh wait, we're supposed to be making things less technical... *facepalm*)

(remote admin for low-tech family member)

computerfreaker wrote: I've heard good things about TeamViewer and 2X, both freeware apps for remote-administration..

Tom T. wrote:I used two paid apps, but they needed to be installed correctly on Gramp's machine, and you can't install it remotely until you install it, if you know what I mean... fortunately, there was a family friend nearby who followed my detailed instruction sheet (call me on a hardline, landline phone to arrange a pre-shared key ) and got the server installed for Gramps, after which we were good. But if there hadn't been, it would have had to have waited for my next visit, and the distance wasn't trivial. But if I hadn't been in the family in the first place, Gramps would have been out of luck...

Yeah, and remote-admin apps are no help, say, for BSOD's. And if you're trying to do something over the phone, Murphy's Law dictates that the non-tech-savvy relative will delete precisely the wrong key in RegEdit, rendering the computer unbootable and starting a family version of World War III.

Tom T. wrote: If we accept for the moment that you've achieved all that, recall the long thread (I'd rather not link it) from the user who challenged whether default-deny JS was necessary for good security. (His wife didn't want to be bothered with NS. I rest my case yet again. )

computerfreaker wrote:I recall that thread... not too pretty.

Tom T. wrote:Here''s another that just came up (they do every once in a while, fairly regularly. And these are only the ones who bother to post.): http://forums.informaction.com/viewtopi ... 632#p13617

You'll note that another Mod *did* link the thread in question, yet OP still said that NS script-blocking wasn't necessary. There is none so blind as he who will not see....

Actually, that sums up the whole problem in a nutshell... but keep brainstorming!

Well, even the best-designed software can't change the most important s/w: the software between the ears. That's what's got to change for security to get more important to people... until then, all we can do is keep brainstorming new idiot-proof ways of doing things and hoping the universe doesn't turn out SuperIdiot v2 until we get IdiotProofApp v3 out the door.

l8r!

computerfreaker wrote:....The point of the quote is still the same though: don't believe everything you see, hear or read....

Lines from "I Heard It Through The Grapevine" (© Motown Records, made famous by Marvin Gaye in 1967, and later used as the theme for the California Raisin Growers)

"They say believe half of what you see -
"Son, -- and none .. of what you hear"

In the sciences, this is known as "healthy skepticism".

(Remote-admin)

computerfreaker wrote: Yeah, and remote-admin apps are no help, say, for BSOD's. And if you're trying to do something over the phone, Murphy's Law dictates that the non-tech-savvy relative will delete precisely the wrong key in RegEdit, rendering the computer unbootable and starting a family version of World War III.

I'd never tell anyone to Regedit over the phone. I'd do it myself with the remote admin tool.
For a BSOD, just try re-booting. If it loops continuously, there's a good chance that Windows has to be reinstalled (happened to me when a boot volume became corrupted somehow) or otherwise take it to a trusted local shop. Definitely not a phone- or remote-admin issue. It's *possible* that resetting BIOS defaults might work, if that's the issue, but you can't get there via a remote-admin program that *runs on Windows* . Shop time.

Cheers!