I'm not involved in Linux Kernel development, nor am I ever likely to be.
I'm hoping to keep the option in people's minds as piece of the solution.
I'm trying to make a reasoned argument based on what appears logical to me. Attacking my credentials doesn't affect the validity of this argument.
In a micro-kernel system, the amount of code which runs in privileged mode is kept to the barest minimum to effectively do the job. The linux kernel includes drivers in protected mode, which means that literally millions of lines of code run in privileged mode, as opposed to the few thousand in a microkernel system. This alone makes the attack surface much smaller when considering threats. It also makes the probability of hung systems much lower because a well written microkernel system can restart a driver. QNX is such a system.
Micro-kernels are only a useful piece of the solution to computer security, the use of a default deny strategy is another, never trusting code is another.
Why do you dislike micro-kernels so much? There must be something specific which made it worth your time to comment. I'm curious to know.
Lots of interesting questions, which I can't answer (especially a 1:30 am)... the bit about how to ask for capabilities is the part that I'm still fuzzy about... not sure how that would work... mostly I assume they are given at runtime, and that's it, which doesn't cover these cases.
Thanks for the comments, I'll ponder them, and try to build a stronger case for this... we really need to fix this before it gets "fixed" for us in a bad way.
I strongly believe that it's possible to reduce the treat of "cyber war" by actually fixing the security problem at it's source, our computers and servers. Imagine if it were possible to greatly reduce the number of security holes on the average pc or server. If this were the case, we wouldn't need to have politically motivated filtering and other types of control to "save us" from our own systems.
The internet is just a big network, and while BGP seems to have it's issues, with some work they can be solved. The network itself is just a "series of tubes", as it's been described in the past, and you don't have to guard the tubes if the ends are secured.
There is a deep design flaw in the operating systems and applications we use on a regular basis. Historically it's been possible to tightly control the code we run, so it was reasonable to trust the code to do its job. This assumption no longer is valid.
We can no longer afford the luxury of trusting our applications.
We can't even afford to trust our drivers with kernel mode.
We can't afford to trust the system processes to stick to their designated roles.
We have to trust some code, why not trust as little of it as possible? Micro-kernels present the smallest amount of code required to manage the operating system. There has been much research in this area, and recently there have been "proven" micro-kernels which theoretically have no flaws in their implementation of their specifications.
Now, the kernel needs device drivers and other system processes to make a usable operating environment for the user and programs. A kernel which doesn't trust its drivers must use a new strategy. One way forward is to use the concept of capabilities. A "capability" is a token / key (really, just a big number) which allows access to a resource. Each device driver, system process, etc... is given the appropriate set of keys to the resources that are required to do the job. If the key isn't present, the access is not allowed.
Thus a disk driver wouldn't get access to the internet. A clock driver wouldn't need to either. The system time demon would get access to a log file, a specific set of internet ports and addresses, and the clock. Any bug or vulnerability in one of these drivers would only affect it, and the capabilities it happened to have at the time.
Applications would have to be re-designed as well, for example, if you want to open a file in OpenOffice, the program opens a system dialog box to get the name and path to a file, it then opens the files as required. The new version would instead call a slightly different dialog box, which would them return the file handle (a capability) to only that file. The save dialog would also be modified in a similar fashion. If there are libraries required, etc... they can be included in the applications home folder. A capabilities based version of OpenOffice would thus work the same way, but be far more secure.
With this approach, we end up with secure systems that are still usable.
I think I've shown fairly well that we must re-design things from the ground, a decidedly non-trivial task, but it is the only way to avoid having government overlords telling us what code we can and can't use. If we wish to own our own systems as free men, we need to get our act together and fix things now, before it's too late and we loose the freedom to write our own code.
The path we are on ends with computers we merely have license to use, secured by the government, censored by the government, rented from big corporations, running applications we rent or buy from app stores. This is a future we need to avoid.
Thanks for sticking with this thread, I think its important to work out a way to express this better so more people can grok cabsec.
Capability based security isn't perfect. Would it be fair to say it's a better system?
The purpose of an operating system is to fairly and securely share the resources of the computer. If the programs running get direct access to hardware without the ability of the OS to manage it, the OS isn't really doing its job... it's more of a program loader (think MS-DOS). Thus the OS should always manage things like network connections, disks, memory, CPU, etc.This is why programs go through the operating system to access the internet.
Here's another way of looking at it.
When you configure a firewall, one of the first rules you put in is default deny. This makes management practical. Instead of blocking threats as you become aware of them, you start with a list of protocols you support, and specify the rules for each.
The current way we do things is like subscribing to a service that lists known bad IP addresses, and ports, then adding each of those as a block rule to our firewall, on an ongoing basis. The rule lists would get very large, very quickly. The firewall performance would plummet.
Additionally, the firewall would not protect against a new hostile host until it was detected, investigated, confirmed to be bad, then put into the services list of bad hosts, then propagated through to the firewall. During this time you're vulnerable to threats from that host.
Delays enumerating bad are always more costly than delays enumerating good, in terms of security.
A capability based system is like that default-deny rule in the firewall. The program can only modify the files, folders, networked resources, that are provided to it, assuming write access is part of that provision. A really strict system would even limit the CPU clock cycle rate and/or count... to prevent system hogging.
Would you agree that this is a much saner way to do things? Thanks for your time and attention.
The current default permissive systems are equivalent to handing over your wallet to the cashier at the checkout counter, and hoping they will only take the right amount of money, and not use your info to sell your house before you get home. When you run a program, it can do anything you can do.
Granny is a lot smarter than you give her credit for, she knows not to hand her purse to the checkout person at the store. She only hands over the appropriate instrument of payment instead of everything. If the system is properly designed with good UI affordances, it should be very obvious when you're handing that kind of power over to something, instead of just letting it run in a sandbox.
However, if Granny does the right thing most of the time, the population of compromised machines would be far lower than today's levels... if you make targets harder to get, and fewer, then botnets get to be much tougher to run, etc.
It's not perfect, and there is no pixie dust, just different underlying design choices.
Having a micro-kernel which is mathematically proven to do what it says is a big step forward.
Having ONLY the micro-kernel run in protected mode, and be the only thing you MUST trust reduces the attack surface by multiple orders of magnitude/
Limiting explicitly the capabilities of a given task makes side channel attacks involving things outside those capabilities impossible. For example, a disk driver doesn't ever have to get access to the network, does it? This prevents the drivers from secretly sending info out on the internet.
It's not a perfect system, but if you can limit the number of bugs which can possibly take out the OS to a few instead of thousands, isn't it a major step in the right direction?
No, you wouldn't have to download it again, you just give one access (as required to do the job) to the other. I think all of this could be done in a very open, transparent, consistent, and friendly way.
I think administration would be fairly simple for such a system. Instead of "installing" programs, which then entwine themselves into the OS, you would simply drop them into a folder. When you wanted to use them, one reasonable default would be that they could only operate in their own folder.
The idea of trusting code to do what it says on the Tin is the big problem here... not the user. If the user has a system that makes everything inherently sandboxed off from everything else, they have a very good shot at not fouling things up. This is especially true if it's obvious and transparent when you have to drag and drop access to the system folder into a task... if the normal experience never required that, they would know its dangerous.
The users aren't as stupid or foolish as a lot of techs believe.
If we took even a fraction of the "cyber" defense spending that's being spent everywhere (on firewalls, virus scanners, spam filters, etc), and put it into a practical, usable, cabsec (capability based security) system we could FIX this problem.
Capability based security is simple in concept.... provide a program, and a list of capabilities (such as read-access to a config file, read-write access to a sandbox directory, read/write access to the internet) to the operating system. The operating system then enforces security so that NO MATTER WHAT, the program can't access any other files or devices.
If each of the system services is properly configured, and the user is provided with the tools that make it trivial to sandbox an application, then they can run code without ever having to trust it. This makes virus-scanning obsolete.
This is a default deny strategy, the opposite of what we have in place now. If it's not explicitly permitted, it CAN'T happen.
Not that kind of capabilities... the kind that are more granular, and assigned by the user, not the OS manufacturer.
I was initially excited to learn that "capabilities" were included in the Android OS... then I learned how hobbled they really were... more like privilege flags then real capabilities.
This looks like a good time to plug the Default Deny security model, as this server might adopt a new Operating System.
If a default deny environment, programs are never trusted, and the OS keeps them within the capabilities they are provided at runtime. This makes it possible to run untrusted code in a secure manner.
Such a system would be MUCH more secure in the long run.
It's also known as Capability bases security, principle of least privilege, etc.
Capability Based Security (CabSec) can SOMEDAY give you a computer which is both usable, and secure. It doesn't trust any program. Thus it's never necessary to try to enumerate goodness or badness. You can forget about the arms race with the virus writers, etc... and get back to work.
I'm not the right person to write it... I hate C, and I've got both a day job, and a young daughter.... but... I'll help someone who can do it. The pieces are falling into place. A version of the L4 microkernel has been proven to be bug free... that's a step in the right direction. Now all we need us the GNU Hurd running on top of it, to enforce capabilities.
My bitgrid idea is simple... an array of 4:4 Look up tables in a grid. This is just the technology needed to make it small and fast enough to do Exaflops. I look forward to this process scaling up.
I read what I thought were the relevant sections of the big PDF file that went along with the article. They know that the actual RAM cell power use would only be 200 KW for an exabyte, but the killer comes when you address it in rows, columns, etc... then it goes to 800KW, and then when you start moving it off chip, etc... it gets to the point where it just can't scale without running a generating station just to supply power.
What if instead of trying to address everything that way, they break up the computing and move it to the data... so that RAM is tied directly to the logic that would use it... it would waste some logic gates, but the power savings would be more than worth it.
Instead of having 8kit rows... just a 16x4 bit look up table would be the basic unit of computation. Globally read/writable at setup time, but otherwise only accessed via single bit connections to neighboring cells. Each cell would be capable of computing 4 single bit operations simultaneously on the 4 bits of input, and passing them to their neighbors.
This bit processor grid (bitgrid) is turing complete, and should be scalable to the exaflop scale, unless I've really missed something. I'm guessing somewhere around 20 megawatts for first generation silicon, then more like 1 megawatt after a few generations.
Fully managed code is an interesting idea, but requires you to trust the code to do it's job, and ONLY it's job... it doesn't protect against design flaws, or the confused deputy problem.
The only code that should be trusted in any computer is the microkernel in the OS.
A web server process should only require: Read access to web content Read/Write access to an already opened internet connection Write access to a logging system process.
If it only has those things, it can't do anything else, no matter how you crash the stack, etc.
Capabilities aren't the same as priviliges or SU flags... they are per resource, not levels.
Capability based security (Cabsec) can provide OS with no exposed vulnerabilities. It's based on an L4 proven microkernel. The only problem is that it's vaporware.
It doesn't have to be. The parts are starting to fall into place, but the open source community has to be made aware of the fact that it is possible to solve computer security, instead of patching it with layers of band-aids.
Just take an old cheap screwdriver and a file (or a dremel) and you should be able to convert it into an iScrew driver in about 2 minutes.
Am I the only one who has done this in the past?
Re:Bad security model still unchallenged... ugh!
on
PC Virus Turns 25
·
· Score: 1
If it's a choice of running a program, or not, security will never happen. It's the wrong choice.
If user has seen other dancing cats and never had to give permission to modify their system folder in the past... they probably will do the right thing and refuse.
You have to assume some good will and common sense on the part of users. Give them better choices and they will do a better job of choosing.
Bad security model still unchallenged... ugh!
on
PC Virus Turns 25
·
· Score: 4, Insightful
There are updates which need to be read past the initial article....
The HEP program also calls for a world-leading program centred at FNAL to probe the Standard Model using a complementary approach of high intensity beams. This program aims to measure the fundamental properties of neutrinos and to develop a new high intensity proton source. In evaluating the proposed Tevatron extension, the P5 committee emphasized the importance of developing this Intensity Frontier program and we have made implementation of this program a cornerstone of future HEP activities.
It seems to me they are going to have to do some redesign to get the beam currents way up, and then they will be back in the game.
Wow... all of this to stop the internet as a threat from happening. Eliminate anonymity as a possibility on the internet, wait a few years until everyone is complacent, and they use it to mop up any stragglers who don't bend to the will of The Powers That Be.
Good thing they aren't doing anything to fix the security model we all rely on, which would leave viruses and botnets as a plausable denyability... oh... wait... they are.... "The App Store", which means no local filesystems, and no way to propagate information outside of what is allowed by the OS.
And then there is the push towards cloud computing, again no local storage.
We'll be ok... but our kids won't... because they will see local storage as a vulnerability, and shun it at all costs.
I think this will all play out in 10-20 years...at least I hope it takes that long.
I had this idea for building a system which allows for the sharing of hierarchies of things across systems. It was in response to the possible demise of Flickr. I called it InterTubes.
The idea is that you create a container (a tube) which holds stuff... photos, blog posts, etc. The "tube" is really just a text file with agreed upon syntax describing the files and their attributes. You trade access to your tubes with friends via ANY communications channel you can find (including the Internet).
The real magic (and hand waving because I don't have ANY code to show for this) is that the final system would synchronize changes to the files (and metadata) whenever you told it to (or via schedule)... You could also build adapters to fit to the tubes, an example would be an adapter that creates thumbnails, or smaller sized images instead of the full size originals held in a tube... this would make sharing LARGE numbers of photos with friends and family easier and quicker in terms of transfer time and size.
Supporting the syncing of metadata would mean that a family member or friend could note on their copy of the tube that they like a certain photo, or who is in it, etc.... and that info could be synced back to the original source.
Slashdot Mirror
I'm not involved in Linux Kernel development, nor am I ever likely to be.
I'm hoping to keep the option in people's minds as piece of the solution.
I'm trying to make a reasoned argument based on what appears logical to me. Attacking my credentials doesn't affect the validity of this argument.
In a micro-kernel system, the amount of code which runs in privileged mode is kept to the barest minimum to effectively do the job. The linux kernel includes drivers in protected mode, which means that literally millions of lines of code run in privileged mode, as opposed to the few thousand in a microkernel system. This alone makes the attack surface much smaller when considering threats. It also makes the probability of hung systems much lower because a well written microkernel system can restart a driver. QNX is such a system.
Micro-kernels are only a useful piece of the solution to computer security, the use of a default deny strategy is another, never trusting code is another.
Why do you dislike micro-kernels so much? There must be something specific which made it worth your time to comment. I'm curious to know.
Lots of interesting questions, which I can't answer (especially a 1:30 am)... the bit about how to ask for capabilities is the part that I'm still fuzzy about... not sure how that would work... mostly I assume they are given at runtime, and that's it, which doesn't cover these cases.
Thanks for the comments, I'll ponder them, and try to build a stronger case for this... we really need to fix this before it gets "fixed" for us in a bad way.
I strongly believe that it's possible to reduce the treat of "cyber war" by actually fixing the security problem at it's source, our computers and servers. Imagine if it were possible to greatly reduce the number of security holes on the average pc or server. If this were the case, we wouldn't need to have politically motivated filtering and other types of control to "save us" from our own systems.
The internet is just a big network, and while BGP seems to have it's issues, with some work they can be solved. The network itself is just a "series of tubes", as it's been described in the past, and you don't have to guard the tubes if the ends are secured.
There is a deep design flaw in the operating systems and applications we use on a regular basis. Historically it's been possible to tightly control the code we run, so it was reasonable to trust the code to do its job. This assumption no longer is valid.
We can no longer afford the luxury of trusting our applications.
We can't even afford to trust our drivers with kernel mode.
We can't afford to trust the system processes to stick to their designated roles.
We have to trust some code, why not trust as little of it as possible? Micro-kernels present the smallest amount of code required to manage the operating system. There has been much research in this area, and recently there have been "proven" micro-kernels which theoretically have no flaws in their implementation of their specifications.
Now, the kernel needs device drivers and other system processes to make a usable operating environment for the user and programs. A kernel which doesn't trust its drivers must use a new strategy. One way forward is to use the concept of capabilities. A "capability" is a token / key (really, just a big number) which allows access to a resource. Each device driver, system process, etc... is given the appropriate set of keys to the resources that are required to do the job. If the key isn't present, the access is not allowed.
Thus a disk driver wouldn't get access to the internet. A clock driver wouldn't need to either. The system time demon would get access to a log file, a specific set of internet ports and addresses, and the clock. Any bug or vulnerability in one of these drivers would only affect it, and the capabilities it happened to have at the time.
Applications would have to be re-designed as well, for example, if you want to open a file in OpenOffice, the program opens a system dialog box to get the name and path to a file, it then opens the files as required. The new version would instead call a slightly different dialog box, which would them return the file handle (a capability) to only that file. The save dialog would also be modified in a similar fashion. If there are libraries required, etc... they can be included in the applications home folder. A capabilities based version of OpenOffice would thus work the same way, but be far more secure.
With this approach, we end up with secure systems that are still usable.
I think I've shown fairly well that we must re-design things from the ground, a decidedly non-trivial task, but it is the only way to avoid having government overlords telling us what code we can and can't use. If we wish to own our own systems as free men, we need to get our act together and fix things now, before it's too late and we loose the freedom to write our own code.
The path we are on ends with computers we merely have license to use, secured by the government, censored by the government, rented from big corporations, running applications we rent or buy from app stores. This is a future we need to avoid.
Thank you for your time, attention, and comments.
Thanks for sticking with this thread, I think its important to work out a way to express this better so more people can grok cabsec.
Capability based security isn't perfect. Would it be fair to say it's a better system?
The purpose of an operating system is to fairly and securely share the resources of the computer. If the programs running get direct access to hardware without the ability of the OS to manage it, the OS isn't really doing its job... it's more of a program loader (think MS-DOS). Thus the OS should always manage things like network connections, disks, memory, CPU, etc.This is why programs go through the operating system to access the internet.
Here's another way of looking at it.
When you configure a firewall, one of the first rules you put in is default deny. This makes management practical. Instead of blocking threats as you become aware of them, you start with a list of protocols you support, and specify the rules for each.
The current way we do things is like subscribing to a service that lists known bad IP addresses, and ports, then adding each of those as a block rule to our firewall, on an ongoing basis. The rule lists would get very large, very quickly. The firewall performance would plummet.
Additionally, the firewall would not protect against a new hostile host until it was detected, investigated, confirmed to be bad, then put into the services list of bad hosts, then propagated through to the firewall. During this time you're vulnerable to threats from that host.
Delays enumerating bad are always more costly than delays enumerating good, in terms of security.
A capability based system is like that default-deny rule in the firewall. The program can only modify the files, folders, networked resources, that are provided to it, assuming write access is part of that provision. A really strict system would even limit the CPU clock cycle rate and/or count... to prevent system hogging.
Would you agree that this is a much saner way to do things?
Thanks for your time and attention.
You're right... you can't fix stupid.
A different analogy might help here.
The current default permissive systems are equivalent to handing over your wallet to the cashier at the checkout counter, and hoping they will only take the right amount of money, and not use your info to sell your house before you get home. When you run a program, it can do anything you can do.
Granny is a lot smarter than you give her credit for, she knows not to hand her purse to the checkout person at the store. She only hands over the appropriate instrument of payment instead of everything. If the system is properly designed with good UI affordances, it should be very obvious when you're handing that kind of power over to something, instead of just letting it run in a sandbox.
However, if Granny does the right thing most of the time, the population of compromised machines would be far lower than today's levels... if you make targets harder to get, and fewer, then botnets get to be much tougher to run, etc.
It's worth trying, isn't it?
It's not perfect, and there is no pixie dust, just different underlying design choices.
Having a micro-kernel which is mathematically proven to do what it says is a big step forward.
Having ONLY the micro-kernel run in protected mode, and be the only thing you MUST trust reduces the attack surface by multiple orders of magnitude/
Limiting explicitly the capabilities of a given task makes side channel attacks involving things outside those capabilities impossible. For example, a disk driver doesn't ever have to get access to the network, does it? This prevents the drivers from secretly sending info out on the internet.
It's not a perfect system, but if you can limit the number of bugs which can possibly take out the OS to a few instead of thousands, isn't it a major step in the right direction?
No, you wouldn't have to download it again, you just give one access (as required to do the job) to the other. I think all of this could be done in a very open, transparent, consistent, and friendly way.
I think administration would be fairly simple for such a system. Instead of "installing" programs, which then entwine themselves into the OS, you would simply drop them into a folder. When you wanted to use them, one reasonable default would be that they could only operate in their own folder.
The idea of trusting code to do what it says on the Tin is the big problem here... not the user. If the user has a system that makes everything inherently sandboxed off from everything else, they have a very good shot at not fouling things up. This is especially true if it's obvious and transparent when you have to drag and drop access to the system folder into a task... if the normal experience never required that, they would know its dangerous.
The users aren't as stupid or foolish as a lot of techs believe.
A trusted, proven microkernel is the only part of a system that one should have to worry about.
The way we currently do it is to trust huge swaths of code with the integrity of everything. That will never work.
If we took even a fraction of the "cyber" defense spending that's being spent everywhere (on firewalls, virus scanners, spam filters, etc), and put it into a practical, usable, cabsec (capability based security) system we could FIX this problem.
Capability based security is simple in concept.... provide a program, and a list of capabilities (such as read-access to a config file, read-write access to a sandbox directory, read/write access to the internet) to the operating system. The operating system then enforces security so that NO MATTER WHAT, the program can't access any other files or devices.
If each of the system services is properly configured, and the user is provided with the tools that make it trivial to sandbox an application, then they can run code without ever having to trust it. This makes virus-scanning obsolete.
This is a default deny strategy, the opposite of what we have in place now. If it's not explicitly permitted, it CAN'T happen.
Not that kind of capabilities... the kind that are more granular, and assigned by the user, not the OS manufacturer.
I was initially excited to learn that "capabilities" were included in the Android OS... then I learned how hobbled they really were... more like privilege flags then real capabilities.
This looks like a good time to plug the Default Deny security model, as this server might adopt a new Operating System.
If a default deny environment, programs are never trusted, and the OS keeps them within the capabilities they are provided at runtime. This makes it possible to run untrusted code in a secure manner.
Such a system would be MUCH more secure in the long run.
It's also known as Capability bases security, principle of least privilege, etc.
Capability Based Security (CabSec) can SOMEDAY give you a computer which is both usable, and secure. It doesn't trust any program. Thus it's never necessary to try to enumerate goodness or badness. You can forget about the arms race with the virus writers, etc... and get back to work.
I'm not the right person to write it... I hate C, and I've got both a day job, and a young daughter.... but... I'll help someone who can do it. The pieces are falling into place. A version of the L4 microkernel has been proven to be bug free... that's a step in the right direction. Now all we need us the GNU Hurd running on top of it, to enforce capabilities.
My bitgrid idea is simple... an array of 4:4 Look up tables in a grid. This is just the technology needed to make it small and fast enough to do Exaflops. I look forward to this process scaling up.
All of the examples you all gave to this point are still conventional CPUs with differences in I/O routing.
I'm proposing something with no program counter, no stack, etc... just pure logic computation.
And no, it's not an FPGA because those all have lots of routing as well.
I read what I thought were the relevant sections of the big PDF file that went along with the article. They know that the actual RAM cell power use would only be 200 KW for an exabyte, but the killer comes when you address it in rows, columns, etc... then it goes to 800KW, and then when you start moving it off chip, etc... it gets to the point where it just can't scale without running a generating station just to supply power.
What if instead of trying to address everything that way, they break up the computing and move it to the data... so that RAM is tied directly to the logic that would use it... it would waste some logic gates, but the power savings would be more than worth it.
Instead of having 8kit rows... just a 16x4 bit look up table would be the basic unit of computation. Globally read/writable at setup time, but otherwise only accessed via single bit connections to neighboring cells. Each cell would be capable of computing 4 single bit operations simultaneously on the 4 bits of input, and passing them to their neighbors.
This bit processor grid (bitgrid) is turing complete, and should be scalable to the exaflop scale, unless I've really missed something. I'm guessing somewhere around 20 megawatts for first generation silicon, then more like 1 megawatt after a few generations.
Fully managed code is an interesting idea, but requires you to trust the code to do it's job, and ONLY it's job... it doesn't protect against design flaws, or the confused deputy problem.
The only code that should be trusted in any computer is the microkernel in the OS.
A web server process should only require:
Read access to web content
Read/Write access to an already opened internet connection
Write access to a logging system process.
If it only has those things, it can't do anything else, no matter how you crash the stack, etc.
Capabilities aren't the same as priviliges or SU flags... they are per resource, not levels.
Capability based security (Cabsec) can provide OS with no exposed vulnerabilities. It's based on an L4 proven microkernel. The only problem is that it's vaporware.
It doesn't have to be. The parts are starting to fall into place, but the open source community has to be made aware of the fact that it is possible to solve computer security, instead of patching it with layers of band-aids.
Just take an old cheap screwdriver and a file (or a dremel) and you should be able to convert it into an iScrew driver in about 2 minutes. Am I the only one who has done this in the past?
If it's a choice of running a program, or not, security will never happen. It's the wrong choice.
If user has seen other dancing cats and never had to give permission to modify their system folder in the past... they probably will do the right thing and refuse.
You have to assume some good will and common sense on the part of users. Give them better choices and they will do a better job of choosing.
The solution to this problem has been known for a very long time... it's the principle of least privilege.
We've had 25 years to wise up and stop using a "default permit" based system and still haven't done so.
Here's a summary of the situation, for those who want to help push things in the right direction.
There are updates which need to be read past the initial article....
It seems to me they are going to have to do some redesign to get the beam currents way up, and then they will be back in the game.
Wow... all of this to stop the internet as a threat from happening. Eliminate anonymity as a possibility on the internet, wait a few years until everyone is complacent, and they use it to mop up any stragglers who don't bend to the will of The Powers That Be.
Good thing they aren't doing anything to fix the security model we all rely on, which would leave viruses and botnets as a plausable denyability... oh... wait... they are.... "The App Store", which means no local filesystems, and no way to propagate information outside of what is allowed by the OS.
And then there is the push towards cloud computing, again no local storage.
We'll be ok... but our kids won't... because they will see local storage as a vulnerability, and shun it at all costs.
I think this will all play out in 10-20 years...at least I hope it takes that long.
I had this idea for building a system which allows for the sharing of hierarchies of things across systems. It was in response to the possible demise of Flickr. I called it InterTubes.
The idea is that you create a container (a tube) which holds stuff... photos, blog posts, etc. The "tube" is really just a text file with agreed upon syntax describing the files and their attributes. You trade access to your tubes with friends via ANY communications channel you can find (including the Internet).
The real magic (and hand waving because I don't have ANY code to show for this) is that the final system would synchronize changes to the files (and metadata) whenever you told it to (or via schedule)... You could also build adapters to fit to the tubes, an example would be an adapter that creates thumbnails, or smaller sized images instead of the full size originals held in a tube... this would make sharing LARGE numbers of photos with friends and family easier and quicker in terms of transfer time and size.
Supporting the syncing of metadata would mean that a family member or friend could note on their copy of the tube that they like a certain photo, or who is in it, etc.... and that info could be synced back to the original source.