The "Can you recover overwritten data?" question was answered a few years ago in the paper Overwriting Hard Drive Data: The Great Wiping Controversy. The conclusion was with an electron microscope you could get 1 bit back but the chance of recovering more than that is negligible (and that is in the new barely used drive scenario).
The last question was basically "Can I use Capsicum to create a program that in turn isolates other arbitrary programs in a meaningful way (e.g. in the style of sandboxie)"?
Hey TR, thanks for the comprehensive replies (to be honest I thought I'd asked so late no one would see them) - you elaborated on things that I did not glean from the presentation. Well done for splitting secomp and secomp-bpf up too. I have a few more questions:
- Does Capsicum only work at the process level? I can't have a more privileged thread that is still uncontained (i.e. still able to perform a blocked syscall) while other threads are contained?
- How do you envision codebases supporting Capsicum in a way that they leaves them still portable to platforms where Capsicum is not available? Is it going to be a case of #ifdefs all the way down?
- Would it be possible to make a sandbox program that uses Capsicum to in turn sandbox another (Capsicum-unaware) program that it goes on to run or is it likely going to be too restrictive for the second program?
- How does this compare to existing (coarse grained) Linux capabilities?
- How does this compare to SELinux?
- Does this complement things like Linux's seccomp?
- What's the overhead compared to the above?
- Will FreeBSD ship a policy for a ssh/sshd?
To answer my own question here's what OS X and Windows do with system wide wifi passwords:
OS X stores the wifi password in the (encrypted) System keychain. The System keychain (System.keychain) is stored in a known location on disk and the material to decrypt it (SystemKey) is also stored in a known location on disk. The permissions on SystemKey file are set to be readable by only root.
What Windows does varies depending on version. For XP the wifi password is converted into a key and this key is stored directly in the registry unencrypted. For Vista and later the wifi password is encrypted (not turned into a key) with the System's Master Key and saved into XML file inside a known path on disk. To reverse this process offline, you need the particular decrypted Master Key used to encrypt the wifi password. Due to the way that Window's DPAPI works there may be many multiple Master Key's, one of which was the one actually used to encrypt the wifi password. All System Master Key's live under a well known path on disk but are encrypted. To decrypt a System Master Key, data from the SYSTEM and SECURITY registry hives has to be used. Permissions on the aforementioned registry hives and Master Keys is tight so even a "regular" Administrator cannot directly access the underlying files while the system is running and some of the files are marked as hidden (but this is by the by for an offline attack).
The issue of passwords being stored unencrypted on media has come up before with Android email passwords, Pidgin passwords and so on. If your attacker can bypass filesystem permissions you are already in a world of pain. One way to mitigate this would be to use a password protected keychain/keyring but this only works if you don't automatically unlock it...
Say that I want my Windows machine to automatically log in as a user when I turn it on. Because of the way Windows works it needs to be able to unlock my account (almost certainly to be able to unlock credential stores that would be otherwise locked), which means that when I enable Windows auto-login my password is going to be saved into the registry in plain text.
Perhaps Mac OS X can magically do better? Well not really - OS X XOR's your password with a fixed key and saves into
If the keys to reverse the encryption are stored alongside the encrypted object you have not gained any more security but are just obfuscating your data - an attacker can simply steal both at the same time, run the decryption algorithm and use the object. To be secure you need to have something your attacker doesn't have access to which is at odds with unattended operation. If you want to have something happen completely unattended (i.e. from power on) fashion you are going to need ALL the information available in a directly usable form at some point and it's going to have to be "unprotected". While saving things like hashes are bit better (as they don't reveal the underlying password which may have been reused elsewhere) someone can still steal the hash and use it as is for accessing that service and in many cases a hash is no good as challenge response is being used to prevent the whole secret from having to be passed.
I do have one question though - what do OS X and Windows when you save things like WiFi/802.11x passwords that are accessible to every user? To what extent do they try and protect their system "keychains" and wouldn't such protection be obfuscation?
GMail will be fetching the images by default but only after the user opens the mail. So it's an improvement because the user's browser and IP address will be hidden (as it will be Google's servers doing the fetching) and it's a step back because it is tracking images will work by default. If you want the old behaviour of not showing images you will need to opt into it so only those who explicitly don't want to be tracked will remain anonymous.
The Windows driver also had much larger spikes in the frame latency than the Intel Linux driver.
That sounds true looking at the summary statistics of the graph but the question is at what frequency and by how much when compared to Linux on the same frames? We know the Linux statistics have at least one peak (of 45) but none are visible on that graph because the Windows values have been drawn over the top of of the other values. It's a bad visualisation of the data and it's hard to learn all that much from it...
Do you remember the days when Linux didn't perform well in this area ?
In all honesty I don't (I remember tearing being more common which is a slightly different issue) which isn't to say it wasn't the case - I'd be grateful for sources which show what it used to be and what it is now with the same hardware. From what little I know, being able to measure OpenGL frame latency has only been possible for a few years on Linux...
The headline is bad/misleading - many of those benchmarks are showing a disparity of more than 10% between the drivers. Using the numbers from the Phoronix article, Linux results are the highest number from any Linux driver (there are many cases where the most recent driver was not the best) to try and prove headline:
Linux = [35.88, 140.90, 43.37, 23.5, 32.23, 19.17, 25.17, 16.68, 99.24, 63.94, 46.80, 29.46]
Windows = [41.47, 162.88, 36.57, 27.0, 31.46, 19.37, 24.47, 16.85, 104.04, 65.15, 55.05, 36.63]
for i in range(len(Linux)):
diff = abs(round((1 - Linux[i]/Windows[i])*100, 1))
"Windows win by %d.1%%" % (diff) if Linux[i] < Windows[i] else "Linux . win by %d.1%%" % (diff)
'Windows win by 13.1%'
'Windows win by 13.1%'
'Linux . win by 18.1%'
'Windows win by 13.1%'
'Linux . win by 2.1%'
'Windows win by 1.1%'
'Linux . win by 2.1%'
'Windows win by 1.1%'
'Windows win by 4.1%'
'Windows win by 1.1%'
'Windows win by 15.1%'
'Windows win by 19.1%'
So out of 12 results, 5 showed a 10%+ difference between Linux and Windows Intel drivers in favour of Windows and 1 showed a 10%+ difference in favour of Linux. The conclusion that the drivers are neck and neck does not follow from the premise for around 40% of the results and that's when being unfairly generous to Linux!
I was about dispute an earlier post but then ran
time factor 18014398777917439
on both a real Pi and a whole machine Qemu pi on a 2.5Ghz Intel machine. The real Pi was 3-4 seconds faster. A Qemu Pi may be faster if you didn't emulate the whole machine and just translated the binary though...
Both upstart and systemd will support unmodified initscripts. It can make your boot slower but it preserves backwards compatibility so your wish has been already been granted (albeit in reverse)!
You can still use startx even under systemd and upstart (e.g. if you boot to runlevel 3 (which is also emulated)) assuming your setup has provided it.
I think I've only ever seen a boot that took ten minutes (or longer) in the case that fsck had to run to check a disk and I'm not counting that. I'm also not including time spent in the BIOS. I guess I should have said "a few minutes" to be clearer though.
These were good admins, there were a lot of NFS3/4 shares and it was part of a Kerberos domain but maybe your setup is better tuned. I don't think it was misconfiguration and seeing how things sped up so dramatically after the change... But if it's that hard to get it right with initscripts that's another nail in their coffin in my book.
Human readable initscripts can be far more complicated than systemd units but it depends massively on the task at hand. Some initscripts can be horrific - the Debian Apache initscript is not simple (but it does a lot so...).
How often do I reboot *nix boxes? Varies massively from "only when glibc and kernel changes are released" (so a few times a month tops) to a few times a day. In my previous example many of the machines were in computer labs so they would shut themselves down every day. When you are watching these machines boot up at start of the day you really notice these things. 40 machines just sitting there with text sporadically appearing just to get to a greeter which Windows 7 reached in less than half the time until the systemd switch wasting students tuition fees in practicals - bleh. I even notice boot times on my VM's at work these days - when I spin up 10 Linux VMs from scratch it's nice seeing them all ready in under 40 seconds. Even on my creaky EeePC it's nice being able to get to the desktop from cold in less than 20 seconds.
I'm happy work has been put into improving boot speed over the years - it really has become much better than it was back in 2001 even though more is being done. Stuff like systemd is even solving some long standing problems which used to require hacks like portreserve so it's not just speed.
At a former university the desktops used Slackware with initscripts all the way up until 2011. These desktops were beefy machines with decent chunks of RAM and SATA disks but would take minutes to finish booting. The administrators there switched the start-up scripts to systemd across a holiday and things became dramatically better - no boot took more than 30 seconds and most disk based boots were sub 15 seconds making the old system look laughable.
I'm glad that Slackware gave the admins the choice because the old way of doing it has had its day. Not everything from the 90s was better...