One of the "features" (back in the day) of running a diskless system was that you could set change policy on the server hosting the file which was completely out of reach of the "client" machine that was running the program. For nearly all of the system files there was no reason for them to change. NetApp turned this into a huge win when they could use snapshots to support multiple VM images with just the small configuration changes.
Given the well known benefit there, and that the processor on your hard drive is about as powerful as your phone, why not have the drive set up files that are 'read only' unless allowed to change out of band. Here is how it would work.
Your disk works like a regular SATA drive, except that there is a new SATA write option which can write a block as 'frozen'. Once written that way the block can be read but not written. You add an out of band logic signal and wire it up to a switch/button that you can put on the front (and/or) back panel. When the button is pressed the disk lets you 'unfreeze' or write frozen blocks, when it it isn't pressed they can't be changed.
Now your hard drive, in conjunction with a locally operated physical switch, protects sensitive files from being damaged or modified.
So basically, there's a switch on my computer which I have to flip every so often or things stop working? Or maybe I can just leave it in R/W mode because I'm tired of flipping a switch every time I ctrl+S...
With a versioning file system, it should be possible to save without overwriting locked blocks. The only time you'd need to flip the switch would be to free up disk space by irreversibly deleting files or old versions of files.
Actually its a switch you would have to switch, when you wanted to update the OS or any file that had been marked as read only.
All it does it convert something which is currently invisible (the bad guys escalate privledges and then can stomp all over anything) to something that requires you to stop and say "ok you can stomp on things."
Typically that would be unexpected if you weren't updating the OS but sure social engineering always works as is mentioned elsewhere.
The goal is just to add depth to the security to slow them down.
I would like to have a physical write protect switch on drives I connect via USB ports. It would be great for backup drives, so you wouldn't inadvertently goof them up when restoring from them. (Like get the arguments reversed in an rsync.)
I used such a lot with floppy disks back in the 1980s.
eh that's load of work for something that'll require constant manual intervention, besides, block level protection is the wrong level of abstraction and will get in the way of getting anything done, unless you rewrite the whole operating system to be aware of that (just run a lsof / openfiles )
a software defined version would be: make an opt in sandbox for processes that ties a folder and it's content to a single executable, with the executable pinned by the operating system and let the whole thing be mediated by the kernel.
of course that's as thigh as the kernel security, but if you're worried by that, offsite incremental backups are a cheaper answer.
Understand that it is isn't required to be set to change files, it is only required to be set to change a block on disk which has been marked as protected. If your OS marked nothing as protected it would never have to be set.
If you look at the time stamp history of your 'system' files on a windows system (C:\Windows\System\*) you will see that the files have a change frequency of approximately once every 3 to 6 months.
That would correlate with when you would need to flip the switch to allow an update (ie very rarely, like 2 or 3 times a year).
Seems like it'd be a lot simpler and more reliable to just rely on the server to create frequent snapshot backups of user data in a place where malware couldn't touch it.
The drive could just not overwrite blocks and expose an interface to access old copies. Flash drives already do this except for the interface to access old blocks.
Similar to this there is a program I use called Faronics DeepFreeze. It allows you to freeze a drive (the OS drive is what I use it for).
The difference is that it allows writes but any modifications are removed on reboot. I use it to lock down public access machines, users get a network drive they can write to but without being able to modify the OS they can't do much damage.
Not the solution your presenting but it works pretty well.
Not entirely sure why you're getting downvoted - I can only assume it's a kneejerk reaction at the mention of DeepFreeze, stemming from residual bitterness due to all the installations of Halo CE that were removed from school computers thanks to DeepFreeze.
I agree with others that append-only is best way to accomplish this. Maybe with an additional feature that specific files won't be overwritten when it starts running out of space. Far as doing stuff on the HD, there were Australian products in high-assurance sector that had user profiles w/ access controls on partitions. Most products like this disappeared since even the military wasn't buying enough of them. Here's one you could build that in that retains lots of good capabilities:
The other reason these products didn't take off is that it's really the operating or file system's job to do this. That's where it's easiest to enforce access control whether using labels or just crypto. There were and are systems that can do that with small, attack surfaces (i.e. TCB's). So, the integrators offer a combination of stronger OS's (eg trusted OS's, separation kernels) for data in use and encrypted drives for data at rest. Two examples: one of the first, security kernels (GEMSOS) enforcing MLS at FS level; a modern, crypto-oriented filesystem with small TCB usable in a variety of setting.
The first one was deployed in the field for a variety of applications including controlled access of files. Similar kernels were used in databases. The other one could be modified to do access control (i.e. write-protect) on files that had been labeled as such by the operating system when it was in a clean state after trusted boot. It would be a configuration sent over IPC to an isolated app w/ privileged access to secure filesystem.
So, there's how I see it happening. The hard disk could also be used as an accelerator by offloading interrupt handling, some file access, and the crypto parts. The filesystem would then be mainly doing startup and handling issues reported by hardware. They'd have to be designed compatibly, though.
The problem is that someone will then work out a way of hacking the drive so that it ignores the physical switch and allows then to change the contents. Then you have lots of inconvenienced users having to use a switch which ends up not protecting them anyway.
Not necessarily. It would be straightforward to engineer the drive such that the switch could not be overridden by firmware updates. Whether they would actually build it this way is another question.
Okay, so I know Windows probably doesn't actually work this way, but from a user interface perspective... what's the rationale on giving an App permanent access to the user's home folder directories? Don't most well behaved apps have a file open / folder open dialog, which should be able to grant access to files at runtime? If the file opening dialog is provided and controlled by the operating system (I realize many, many legacy apps work differently in Windows) then the OS can silently grant permissions at the time of open, rather than letting apps either have free reign or no access at all.
I feel like this is the expected behavior anyway; Power Users may run utilities that need to touch the whole system, but most regular users are doing pretty good to juggle more than a handful of open files in their mental model of the machine while they're using it. The idea of file permissions is already pretty foreign to the average end user. Applications already have a designated area (%APPDATA%) where they can store their temporary files and things, so perhaps the documents folders should be more locked down by default.
The main problem and is that the file open dialogue generally runs in the app's memory space, at which point we can't stop the app corrupting it in any way it likes.
I hope we are moving to a world where apps are built of seperate processes, most of which have minimal access. If nothing else, this will make many old buggy C libraries (including code I have written) much less dangerous.
Heck, most CLI tools keep credentials in text files which are very easily read by random apps. Sometimes people will keep all a bunch of API keys in a single .bashrc file, which gets passed down to every child.
On macOS I've been experimenting with creating a separate keychain for storing most of my API keys. Once keys are stored securely, you can write a wrapper for each tool. The wrapper just has to read the value from the keychain and call the original. That way you lower the changes of keys being needlessly shared. It has good UX too, since it only has to prompt you when it's first used. Although for that to really work I think you have to sign the wrapper, otherwise anyone can just edit it.
It's unfortunate that Windows seems to conflate sandboxing applications and central control of which applications are available. I'd love all the apps on my system to be sandboxed, but not if I lose the ability to install "unapproved" apps at the same time.
This is one of the "common dialogs", and as mentioned elsewhere it runs in the app's memory space so you can, if determined enough, mess about with them. They also run all your shell extensions, which is a fun place to put malicious code.
What might be viable is UAC-style privilege requesting to get out of a sandbox, but that kind of thing was really unpopular when UAC was introduced with Vista.
this is essentially how the sandbox works on macos from what I understand. 90% of applications should work fine for this. Some though like antivirus (as an example) can't really do so.
Reality is that almost all applications do not use sandbox, unless they are forced too. At least in my experience. I have 16 installed apps and only 2 from AppStore. Check out Android. It has very fine-grained permissions model. But most developers don't care and ask a lot of permissions even for simplest apps. It turns out that users don't care too. I'm not sure how it works for iPhone, where App requests access to some specific very privacy-related functionality, like location or address book, but I think that even on iPhone most users will press "Yes" without second thinking or even careful reading.
I've always wondered why Windows and other OSes don't offer a 'cold storage' area where you need thaw out files before editing. Files not modified within a selected time freeze from further modification. I've got plenty of files that are archived that I'd never want to change, but it's a hassle to unmount/remount just to add a new file to an existing directory.
How about just enabling Shadow copies by default! I don't understand why Windows has great "Time machine like features", but every fucking time I right click and go to Properties and look at the "Previous versions" tab and it is completely empty.
I have seen otherwise smart, famous people flip out in public when they learn that Windows has a built in window recorder. Same folks have no concerns with their video drivers doing the exact same thing.
That said, I think the only really safe way to do this is a history chain that lives off-site. That means copies to azure, and even with great crypto and blocklists, that's not going to fly in the news.
My observation is that people who buy Macs also buy an external drive for Time Machine but Windows PC buyers don't usually buy an external drive and turn on File History. Slightly different culture, I guess.
I'd also really like Microsoft to develop the Application Guard (app in a VM) feature faster and make it widely available to almost any app, or at least any browser, and of course to everyone, not just enterprise users.
Microsoft has some interesting new security features on its roadmap. Unfortunately, 90% of them are for enterprise users-only and some only for its own applications.
It also wouldn't hurt to overhaul/replace UAC with something better, but I imagine that would require deeper architectural changes (which I think would be worth the pain).
Microsoft should also push users towards creating a Standard account when installing Windows, and setting up an Admin password, too. It shouldn't be too difficult/disruptive. They just need to create an easy process for it at installation.
The vast majority of Windows malware infections happen because users are also Admins. This alone would give Windows a huge security boost on average.
Once they do this, they could also start encrypting Windows devices by default with the Admin key, similar to how Android does default encryption.
Windows is pretty much the last major operating system not to encrypt by default. Hopefully, if they do this, they at least give users the option to keep the key locally, and not automatically upload it to Microsoft's servers, as they do now if you login to your Microsoft account.
The file would still be there and available, even more so as it would be "frozen readonly", you just get a request on write access.
Whereas with drives you don't have access to the file if it's not mounted, you have to know on which drive the file you're looking for is, go through the mounting process, then actually find the file. And if you want to alter the file you have to remount the entire thing, and possibly need to track down that one daemon which still has a handle open and prevents you from unmounting it.
For Windows it could just prompt the user when an application attempts a write operation; just like UAC, if permission is granted the calling application wouldn't even notice the difference except for the pause while the open for write access call blocks pending user permission. Done at the same level as UAC in theory it should be impossible for malware to bypass approval, heck I'd even be happy typing my user account password to thaw it out.
My concern is first off, this seems like it is going to break a massive number of applications. It also seems that they are pushing this layer of access management that doesn't have proper support on any platform but UWP.
I see this as Microsoft taking yet another step to force people to move to their new Appstore model. by choking the access to the operating system away from any other platform, which I find really amusing because their own top tier applications aren't built on these platforms (office, visual studio, etc..).
I imagine Office, VS etc are too big to "port" to Appstore model. Also people still use these applications in Windows 7 and so that would mean having two parallel versions of the same app and release features and support for both.
So last ransomware we seen in the news actually tried to reboot system and encrypt files before OS is loaded. So unless that new tech gonna protect MBR (which should be protected anyway) - not sure how it going to stop encryption.
Fun fact, if you manage to replace the osk.exe (on screen keyboard) and flip the registry bit that loads it before the login screen, it will be executed as SYSTEM, with full disk and network access. It can also interact with the Winlogon window and stealthily phish the password of any user.
Heck, it can even self-delete before any user logs in.
Why programs before the login screen and the screen itself don't run in a sandboxed account is beyond me.
Every windows user with a laptop is running in local admin mode. I've demonstrated this for german TV by having a file less UAC exploit install osk.exe malware, then have this send the password of the next user logging in via SMS to the "attacker". The deleting itself (and remove any anti virus install).
Fun Fact #2, an easier way is the on screen accessibility tools, which if you replace with cmd.exe via Windows very own Recovery Console (on the OS DVD/USB), you can just click the Accessibility icon on the logon screen and get a SYSTEM level command prompt. It's even documented as a way in (Google is your friend) if you forget your Domain Controller password.
I find it shocking that this even works. However I'd be a liar if I didn't say it saved my arse once.
Except Microsoft leaked their "golden" Secure Boot keys. I don't know all the details of how Secure Boot works, but I am under the impression that if malware gets Administrator access to the system, it can install it's own bootloader using one of the leaked keys. Then bypassing Bitlocker is as easy as presenting a fake BitLocker screen asking the user to enter the key.
Wouldn't secure boot just prevent you from booting into the invalid MBR? At that point your files are already encrypted and your MBR already over-written, Secure boot is just preventing further exploitation.
Completely unrelated, but am I the only with an impression that MS has switched Windows into a rolling release OS (like Gentoo or Arch) with infinite updates of Windows 10? This would be a genius move to solve the issue of the users remaining on the old unmaintained release like it was with XP, and like it is now with 7.
It's not going to do much for targeted attacks, but there are definitely ways to limit the damage for large-scale ransomware attacks. As it is right now, ransomware doesn't even need to bother with privilege escalation because files valuable to users are most likely owned by them. Not to say that all ransomware malware sticks to just user privileges, but it's usually enough do get the job done.
Having a sort of firewall for file systems that's enforced by the system means that in addition to getting code to run with user privileges, the malware authors need to trick the victims into giving the software root (which might be impossible on enterprise networks), or use a privilege escalation vulnerability to do that.
Of course, people could still click through prompts, allow access to all apps due to warning fatigue, etc., but it's an improvement - if done correctly.
Given malicious code is hidden in applications that appear to be safe or appealing to users I don’t think they are usually willingly downloading malicious code.
> If an app attempts to make a change to these files, and the app is blacklisted by the feature, you’ll get a notification about the attempt
So it's allow default? That sounds useless.
We need a deny default thing. Like Little Snitch but for disk. Every time an app accesses a directory it hasn't accessed before, ask. (Skip asking when files are opened using the system "Open file" dialog for a bit less annoyance.)
Readit News
Given the well known benefit there, and that the processor on your hard drive is about as powerful as your phone, why not have the drive set up files that are 'read only' unless allowed to change out of band. Here is how it would work.
Your disk works like a regular SATA drive, except that there is a new SATA write option which can write a block as 'frozen'. Once written that way the block can be read but not written. You add an out of band logic signal and wire it up to a switch/button that you can put on the front (and/or) back panel. When the button is pressed the disk lets you 'unfreeze' or write frozen blocks, when it it isn't pressed they can't be changed.
Now your hard drive, in conjunction with a locally operated physical switch, protects sensitive files from being damaged or modified.
All it does it convert something which is currently invisible (the bad guys escalate privledges and then can stomp all over anything) to something that requires you to stop and say "ok you can stomp on things."
Typically that would be unexpected if you weren't updating the OS but sure social engineering always works as is mentioned elsewhere.
The goal is just to add depth to the security to slow them down.
I used such a lot with floppy disks back in the 1980s.
a software defined version would be: make an opt in sandbox for processes that ties a folder and it's content to a single executable, with the executable pinned by the operating system and let the whole thing be mediated by the kernel.
of course that's as thigh as the kernel security, but if you're worried by that, offsite incremental backups are a cheaper answer.
If you look at the time stamp history of your 'system' files on a windows system (C:\Windows\System\*) you will see that the files have a change frequency of approximately once every 3 to 6 months.
That would correlate with when you would need to flip the switch to allow an update (ie very rarely, like 2 or 3 times a year).
Deleted Comment
The difference is that it allows writes but any modifications are removed on reboot. I use it to lock down public access machines, users get a network drive they can write to but without being able to modify the OS they can't do much damage.
Not the solution your presenting but it works pretty well.
http://securesystems.com.au/index.php/high-assurance-silicon...
The other reason these products didn't take off is that it's really the operating or file system's job to do this. That's where it's easiest to enforce access control whether using labels or just crypto. There were and are systems that can do that with small, attack surfaces (i.e. TCB's). So, the integrators offer a combination of stronger OS's (eg trusted OS's, separation kernels) for data in use and encrypted drives for data at rest. Two examples: one of the first, security kernels (GEMSOS) enforcing MLS at FS level; a modern, crypto-oriented filesystem with small TCB usable in a variety of setting.
http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=048...
https://www.usenix.org/legacy/event/atc11/tech/slides/weinho...
The first one was deployed in the field for a variety of applications including controlled access of files. Similar kernels were used in databases. The other one could be modified to do access control (i.e. write-protect) on files that had been labeled as such by the operating system when it was in a clean state after trusted boot. It would be a configuration sent over IPC to an isolated app w/ privileged access to secure filesystem.
So, there's how I see it happening. The hard disk could also be used as an accelerator by offloading interrupt handling, some file access, and the crypto parts. The filesystem would then be mainly doing startup and handling issues reported by hardware. They'd have to be designed compatibly, though.
I feel like this is the expected behavior anyway; Power Users may run utilities that need to touch the whole system, but most regular users are doing pretty good to juggle more than a handful of open files in their mental model of the machine while they're using it. The idea of file permissions is already pretty foreign to the average end user. Applications already have a designated area (%APPDATA%) where they can store their temporary files and things, so perhaps the documents folders should be more locked down by default.
I hope we are moving to a world where apps are built of seperate processes, most of which have minimal access. If nothing else, this will make many old buggy C libraries (including code I have written) much less dangerous.
On macOS I've been experimenting with creating a separate keychain for storing most of my API keys. Once keys are stored securely, you can write a wrapper for each tool. The wrapper just has to read the value from the keychain and call the original. That way you lower the changes of keys being needlessly shared. It has good UX too, since it only has to prompt you when it's first used. Although for that to really work I think you have to sign the wrapper, otherwise anyone can just edit it.
The problem is getting everyone on the store train, and to move away from classical desktop.
https://msdn.microsoft.com/en-us/library/windows/desktop/bb7...
This is one of the "common dialogs", and as mentioned elsewhere it runs in the app's memory space so you can, if determined enough, mess about with them. They also run all your shell extensions, which is a fun place to put malicious code.
What might be viable is UAC-style privilege requesting to get out of a sandbox, but that kind of thing was really unpopular when UAC was introduced with Vista.
https://docs.microsoft.com/en-us/windows/uwp/files/quickstar...
Open/save file dialogs basically return just file path. Actual file access is a separate API call.
Requiring interactivity in all scenarios would hurt UX badly, as UAC story proved.
"Windows eats all my hard disk!! I've updated to <windows xy>/Windows did an update and now all my disk space is gone!!! Don't update!!!!"
"New MS update steals your disk space, here's how to stop it"
And so on, and so on.
I have seen otherwise smart, famous people flip out in public when they learn that Windows has a built in window recorder. Same folks have no concerns with their video drivers doing the exact same thing.
That said, I think the only really safe way to do this is a history chain that lives off-site. That means copies to azure, and even with great crypto and blocklists, that's not going to fly in the news.
Microsoft has some interesting new security features on its roadmap. Unfortunately, 90% of them are for enterprise users-only and some only for its own applications.
It also wouldn't hurt to overhaul/replace UAC with something better, but I imagine that would require deeper architectural changes (which I think would be worth the pain).
Microsoft should also push users towards creating a Standard account when installing Windows, and setting up an Admin password, too. It shouldn't be too difficult/disruptive. They just need to create an easy process for it at installation.
The vast majority of Windows malware infections happen because users are also Admins. This alone would give Windows a huge security boost on average.
https://www.avecto.com/news-and-events/news/94-of-critical-m...
Once they do this, they could also start encrypting Windows devices by default with the Admin key, similar to how Android does default encryption.
Windows is pretty much the last major operating system not to encrypt by default. Hopefully, if they do this, they at least give users the option to keep the key locally, and not automatically upload it to Microsoft's servers, as they do now if you login to your Microsoft account.
Go to macOS user forums and you will see lots of discussions about how to turn off Gatekeeper or be "always root" user.
If the malware gets privileged access, it's game over. If it can't, good file system permissioning fixes the problem.
Whereas with drives you don't have access to the file if it's not mounted, you have to know on which drive the file you're looking for is, go through the mounting process, then actually find the file. And if you want to alter the file you have to remount the entire thing, and possibly need to track down that one daemon which still has a handle open and prevents you from unmounting it.
Can you explain the thawing procedure, and how a normal everday user would experience it?
I see this as Microsoft taking yet another step to force people to move to their new Appstore model. by choking the access to the operating system away from any other platform, which I find really amusing because their own top tier applications aren't built on these platforms (office, visual studio, etc..).
The next version of Office and Note for Windows 10 are going to be store only.
At Build they also had people from Adobe, Cakewalk and Kodi showing their desktop apps ported to the UWP via the Desktop Bridge.
Like they did with WPF and Visual Studio, they are pushing everyone into the train by dragging their own devs into it.
Except Visual Studio isn't using anything newer than WPF yet, is it?
Heck, it can even self-delete before any user logs in.
Why programs before the login screen and the screen itself don't run in a sandboxed account is beyond me.
Every windows user with a laptop is running in local admin mode. I've demonstrated this for german TV by having a file less UAC exploit install osk.exe malware, then have this send the password of the next user logging in via SMS to the "attacker". The deleting itself (and remove any anti virus install).
I find it shocking that this even works. However I'd be a liar if I didn't say it saved my arse once.
https://www.theverge.com/2015/5/7/8568473/windows-10-last-ve...
Deleted Comment
To be fair, software is a recent human endeavor, and except for Emacs, I'm not familiar with software versions over 10.
In databases, Oracle and Informix are both on version 12.
I think the lack of high version numbers is not necessarily paranoia, but simply that there isn't much software that's old enough yet.
Do I miss something and this is actually a viable security approach?
Having a sort of firewall for file systems that's enforced by the system means that in addition to getting code to run with user privileges, the malware authors need to trick the victims into giving the software root (which might be impossible on enterprise networks), or use a privilege escalation vulnerability to do that.
Of course, people could still click through prompts, allow access to all apps due to warning fatigue, etc., but it's an improvement - if done correctly.
It's a virtual certainty that users will download malicious code, so as a security person you're left trying to mitigate the impact when they do.
So it's allow default? That sounds useless.
We need a deny default thing. Like Little Snitch but for disk. Every time an app accesses a directory it hasn't accessed before, ask. (Skip asking when files are opened using the system "Open file" dialog for a bit less annoyance.)