Hacker News Reader

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...

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.

VM snapshots work this way, e.g. persist changes, discard changes and revert to previous snapshot.

This is more feasible with a file system where snapshots are efficient, like ZFS. With client-side virtualization (e.g. Qubes), snapshots can be done outside of Windows.

Sounds like exactly what UAC did in Vista. It prompted so much that people either turned it off, or just blindly hit OK. Subsequent versions toned down the alerts to what we have now in Win10. Making it a hardware switch doesn't change the fact that the average user will just quickly learn to flip the switch anytime something doesn't work quite right and we are right back where we started.

The average user is never going to be protected by something they can switch on and off at will. They will never understand the complexity around when it is OK to switch it off.

How is two or three times a year like UAC?

If you want to declare program files and system settings unprotected along with the user files, you could just continue to use UAC and make it only trigger two or three times a year. It'll protect you about as well as the switch, which is very little.

It seems like there's a spectrum of outcomes here. As a user, I don't particularly care about system files, I care about the state of the system. In fact, if all this does is protect system files, then a ransomware attack would just wipe out all my user files and revert the machine back to a fresh install-- an identical outcome to if I just reformatted the drive and reinstalled Windows. Not helpful!

Really, this scheme needs to include the entire contents of the drive-- "freezing" the restore points Windows makes automatically. Now the tradeoff is how often you annoy the user/how fresh the backups will be. Once a year is obviously too infrequent, once a second is too often. Once a week, or month. Maybe do it at the same time as Windows does a system update, as you suggest.

You don't need fancy hardware support for this, just a NAS backup box with a client that doesn't let you erase older snapshots.

Sorry, I didn't explain well. I wasn't really making a point about the frequency. The point I meant to make was that anything the user learns has to be switched to continue proper functioning won't protect them, because they will just switch it when the malware requests it too. Which is exactly what has happened with UAC.

The constant uac notification wasn't a windows thing as much as apps. While windows itself was more or less reasonable with the warnings, lots of apps assumed it's still xp (or just haven't been updated) and they can do whatever, wherever.

The OS we can reinstall, we don't care about its files. We care about our Excel files with the accounting books in them that we can not put in read only mode because we keep them open and update them every day.

Something like a versioning system with the past versions Immutable.

People might not want to use that since you can't redact mistakes that could get you into trouble. There are a wide variety of scenarios that are mostly innocent but would need to be addressed. And if you can destroy data, that leads to the original problem.

There's already no guarantee your data gets deleted on modern filesystems. And in corporate environments you can assume your data gets backed up transparently in the background all the time. Beyond making it more explicit I don't think anything would change in practice.

Reminds me of this XKCD: https://xkcd.com/1200/

Point is, nobody cares about the OS files. They care about their documents and data, and their logins to various secure systems. Securing system files alone doesn't really help much.

Probably the best thing is basically to be a Chromebook - the OS is signed and locked-down, can't ever be changed except for by signed updates from the mothership. Documents are meant to be stored entirely on the cloud. No support for running (unsigned?) apps locally, and even if they did, it wouldn't do much, because all of the data is on the cloud anyways.

Came to basically say the same... Also, a big fan of Chromebooks for most users... especially as many intranet/internal applications are now web based.

Well of course, but one reason why people want to make system files secure is because if those can be messed with it makes it so much easier to do all the bad things in that XKCD - without detection even.

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.

So "append only" not "disable writes", got it. I could see that being useful in auditing logs.

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.

Wasn’t write protection a thing on old USB flash drives? I have a 32 MB drive somewhere that has a WP switch on it.

I remember looking for those models some years back.

http://www.fencepost.net/2010/03/usb-flash-drives-with-hardw...

https://eikonal.wordpress.com/2010/05/21/usb-thumb-drives-wi...

Ought to take a look again if they're available now. Even if they still only come with a few gigabytes of storage there would be some nice applications.

https://www.digitalintelligence.com/products/usb3_write_bloc... exists, but they're not priced for consumers.

SD cards have this. Is very useful.

except the sd card switch is driver based, not hardware

Software based switches are not reliable, sigh.

MicroSD adapter cards come with hardware switches. At least all mine did.

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).

if you rely on the os to mark protected sectors, the physical switch becomes moot. malware can just keep quiescent til a privileged action is required, especially if the switch is a disk wide all-or-nothing

also, system files aren't really the target here, the issue are userland files - who cares that the os is safe when the data is crypted

Well...but I don't know which files will be updated when, and Windows 10 likes rebooting itself automatically to update files. On top of that, I'm not terribly worried about malware encrypting Windows, more like it encrypting my own data files, which change much more often than several times a year.

Some malware gets delivered to my computer as a new file, and the code that it contains begins to execute as an admin user. Its attempts to mess around with C:\Windows is thwarted by block-level protection. Instead, it goes into C:\Users\Me and starts encrypting stuff (not block-level protected, because it's all constantly changing anyhow). So, it can't modify the Windows system files that I could just re-install anyhow, but it can modify the creative output on my disk that only exists in a month-old backup copy, or something.

Given that scenario, I'm not sure how much help the ability to write-lock blocks would be.

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.

Why not just mount / as a ramdisk then? Live CDs do something like that IIRC where the file is read from the CD/USB and any changes are kept in RAM.

Can you do that with Windows? I also imagine you'd want ram. The public access machines I manage are not exactly powerful.

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:

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 Copy on Write can give you all the benefits you seek, easier. In case of fire, rollback changes. Daily snapshots when verified as OK.

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.