Encrypted safe

[rustleg]

I listed a whole load of things in my wishlist post elsewhere on this forum and you kindly answered the points, but I think you missed one thing which I expressed as follows (apologies if I missed your answer)
"Here I'd like an encrypted "safe" to put in a list of banking passwords, a few text files and spreadsheets, then write to somewhere such as my normal data drive so I can do a cloud backup of this - or allow cloud backup (...) to back up this safe from the USB stick."

You mentioned KeepassX but I think this is an application to store passwords and some other stuff but not complete files.

I have a small set of files, which includes a text file of internet banking passwords, memorable info, etc = my crown jewels, but also a couple of spreadsheets with financial data in. Currently I use 7zip in Linux to archive these with AES256 encryption, and the archive sits on my NAS. I have 2 simple small scripts, to Zip and Unzip these files to/from /tmp (which is mounted in RAM) using a command line version of 7zip. The password is entered dynamically not stored (except by 7zip in the archive).

Clearly this is a home grown solution and there may be holes in it which a security expert would see. I wonder if you have any suggestions as to how I could approximately duplicate such an operation in KNOS.

At least could I run my scripts in you Linux emulator if possible? Although of course I'd need to update the scripts to write the temporarily unzipped files to somewhere which gets trashed when KNOS quits. The spreadsheets use Libre Office and text files gedit and I set preferences not to create backups within these applications.

Of course it would be nice if some sort of container could be integrated into the OS somehow so the applications read and write directly from a file within the container as if it were a drive without them knowing anything about encryption. This container could then be sent to the cloud directly as it would not need further encryption (although of course the OS would need to know not to decrypt them automatically when uploading). Is this like how Truecrypt works?

Am I barking up the right tree here?

[Kevin McAleavey]

Correct on your assumption of what Keepassx is for - it was a request ages ago for password storage and management as an alternative to the "keyring" one of our customers wanted, so we provided it since it was requested and we thought it to be quite a useful addition.

You might be amused to know that as another part of our KNOS design, we support all known viable archiving formats as well. 7Zip is just one of those already inside KNOS. We expose all of these various archive formats through our GUI "file-roller" which makes unpacking them as easy as double-clicking on the archive and we'll figure out how to extract it, even ask for a required password and such. And if you right click on a file or folder, there is an option to "compress" and in the selector, you can choose any desired format including 7z right at the top. There are also other options available including encrypting, password protect and such as well.

You can create a folder, or highlight several files at once, clicking the first file choice, then hold down the ctrl key and select additional files and once they're all highlighted, right click and "compress" and there you go.

Command-line use of "p7zip" is aready built into KNOS as well - the file is located in /usr/local/bin/p7zip if you want to use that script. Unless there are some squirrely Linux commands in it, should run as is in KNOS if it's a standard sh/bash/csh/ksh script.

Now THAT all said, we're planning to add ccrypt and ccryptgui to KNOS ... go have a look here and see if that might be a better option for you. We were planning to include them in the release as well!

www.softwaremustbefree.eu/en/ccryptgui/

ccrypt.sourceforge.net/

[rustleg]

Apr 29, 2012 2:14:59 GMT -5 Kevin McAleavey said:

Correct on your assumption of what Keepassx is for - it was a request ages ago for password storage and management as an alternative to the "keyring" one of our customers wanted, so we provided it since it was requested and we thought it to be quite a useful addition. The only negative would be that it seems it is currently being rewritten and the current version's database isn't compatible with the version 2. You can convert back from 2 to 1 but I couldn't find if it's possible to go from 1 to 2 although I'd hope that the author would provide a utility as part of his rewrite.

You might be amused to know that as another part of our KNOS design, we support all known viable archiving formats as well. 7Zip is just one of those already inside KNOS. We expose all of these various archive formats through our GUI "file-roller" which makes unpacking them as easy as double-clicking on the archive and we'll figure out how to extract it, even ask for a required password and such. And if you right click on a file or folder, there is an option to "compress" and in the selector, you can choose any desired format including 7z right at the top. There are also other options available including encrypting, password protect and such as well.

You can create a folder, or highlight several files at once, clicking the first file choice, then hold down the ctrl key and select additional files and once they're all highlighted, right click and "compress" and there you go.

Command-line use of "p7zip" is aready built into KNOS as well - the file is located in /usr/local/bin/p7zip if you want to use that script. Unless there are some squirrely Linux commands in it, should run as is in KNOS if it's a standard sh/bash/csh/ksh script.

Now THAT all said, we're planning to add ccrypt and ccryptgui to KNOS ... go have a look here and see if that might be a better option for you. We were planning to include them in the release as well!

www.softwaremustbefree.eu/en/ccryptgui/

ccrypt.sourceforge.net/

Re Keepass, I agree with the other customers preference for this password storage solution rather than keyrings assuming that you could open the database somewhere else and not be dependent on your own system's internal code and storage in case it disappeared for whatever reason.

Your file-roller seems to do the necessary here, assuming the encryption is good. Also the ccrypt and ccryptgui appear to offer something even more automatic although in reality I still need to delete the folder in which it stores the plaintext files, which it appears to do itself provided you use "File Close". However this is in a fixed location $HOME/.ccryptgui-tmp - I expect I'd substitute KNOS for HOME. As this is a hidden folder it may be easy to forget it's there.

What would be nice is a folder which is automatically trashed on reboots, overwriting of contents first. Then I'd put the plaintext files in there.

And you might want to tweak ccryptgui to do the same by default? Or you could at least automatically trash their $HOME/.ccryptgui-tmp on reboot, since no-one will want the plaintext to survive, especially if they missed deleting it and didn't see it because it was hidden. It seems to me because it is hidden there is an implication that the author considers that the user doesn't need to access it. I think they could change their standard practice here to make it safer for the average user.

Ccryptgui says "it is possible to open the encrypted files with their standard application". I think it means you click on the file in Ccryptgui's file selection window. I presume it saves the file automatically back over the existing copy. My practice is to unzip to a temporary place, operate on the file in clear then rezip (7z format) with a generated filename which includes the time and date, so giving me a new version without destroying the old one.

I guess this begs the question, am I allowed to create simple scripts (such as the bash script I currently use - copy on request) so I can control the detailed process? Looking at the p7zip script in Mint (not got KNOS open at present) it doesn't seem to offer anything extra for me over the base 7zr which it uses, so presumably I could stick to using 7zr in a script. Maybe this was created to allow people to use the gzip syntax they already know?

In my solution it's easy for my wife to click on an icon on the desktop to unzip, deal with the files with standard applications, then hit the zip icon which automatically saves a new encrypted copy. I currently run with /tmp in RAM so aside from something very spooky looking at RAM after the event, it is trashed on reboot. Hence my desire for some equivalent place in KNOS.

[Kevin McAleavey]

Apr 29, 2012 13:37:04 GMT -5 rustleg said:

Re Keepass, I agree with the other customers preference for this password storage solution rather than keyrings assuming that you could open the database somewhere else and not be dependent on your own system's internal code and storage in case it disappeared for whatever reason.

Your file-roller seems to do the necessary here, assuming the encryption is good. Also the ccrypt and ccryptgui appear to offer something even more automatic although in reality I still need to delete the folder in which it stores the plaintext files, which it appears to do itself provided you use "File Close". However this is in a fixed location $HOME/.ccryptgui-tmp - I expect I'd substitute KNOS for HOME. As this is a hidden folder it may be easy to forget it's there.

What would be nice is a folder which is automatically trashed on reboots, overwriting of contents first. Then I'd put the plaintext files in there.

And you might want to tweak ccryptgui to do the same by default? Or you could at least automatically trash their $HOME/.ccryptgui-tmp on reboot, since no-one will want the plaintext to survive, especially if they missed deleting it and didn't see it because it was hidden. It seems to me because it is hidden there is an implication that the author considers that the user doesn't need to access it. I think they could change their standard practice here to make it safer for the average user.

You'll be pleased to know that there's already a nice little (undocumented so far) solution built right into KNOS. On the application backups, we have a hidden file in the KNOS ($HOME) directory called ".not.txt" which contains a list of files *NOT* to backup when you backup settings. This is primarily for privacy purposes to ensure that certain things in your session do not "persist." Simply add the .ccryptgui-tmp/* on a line by itself at the end of what's already in there and presto! It's gone and never backed up.

Ccryptgui says "it is possible to open the encrypted files with their standard application". I think it means you click on the file in Ccryptgui's file selection window. I presume it saves the file automatically back over the existing copy. My practice is to unzip to a temporary place, operate on the file in clear then rezip (7z format) with a generated filename which includes the time and date, so giving me a new version without destroying the old one.

I guess this begs the question, am I allowed to create simple scripts (such as the bash script I currently use - copy on request) so I can control the detailed process? Looking at the p7zip script in Mint (not got KNOS open at present) it doesn't seem to offer anything extra for me over the base 7zr which it uses, so presumably I could stick to using 7zr in a script. Maybe this was created to allow people to use the gzip syntax they already know?

Sure can! What you want to do is create those scripts in your KNOS ($HOME) "folder" and then go in and set the permissions for read-only for KNOS, KNOS group and probably nothing for "everybody" ... be sure to check off "make executable" and that way your scripts will be safely run only manually, plus they'll get backed up as well.

You can then experiment with the script to ensure that it works properly for you in KNOS and you should also be aware that 7zr is already built into KNOS, so have at it since it's already there as a command line function. I'd be willing to bet that your scripts will work just fine although the file structures of KNOS are a bit different from Linux. Since you're a paid customer of course, paid support is included in all of that so feel free to email me if you need any help with it.

In my solution it's easy for my wife to click on an icon on the desktop to unzip, deal with the files with standard applications, then hit the zip icon which automatically saves a new encrypted copy. I currently run with /tmp in RAM so aside from something very spooky looking at RAM after the event, it is trashed on reboot. Hence my desire for some equivalent place in KNOS.

/tmp in KNOS is memory-only as well, so you can do it there or you can do it in the KNOS "folder" or any of its subdirectories. Anything you do not want backed up can be added to that ".not.txt" file and won't be backed up if you don't want it to. I think we can make you quite happy just as things already are as far as that goes.

[rustleg]

All sounds very good. That .not.txt file sounds useful for ccrypt, but I may just stick with putting my cleartext files in /tmp for my home-grown scripts since then I don't have to worry about what new files I create in my safe. Of course I need to watch if any applications create automatic backups. I think a ccrypt user also has that issue.

As far as I am aware gedit saves its backups in the same folder so this isn't a problem if I'm using /tmp. For Libre Office you can customise the paths. So maybe these ought to be added to .not.txt. I note that temporary files are in /var/tmp which I expect will be in RAM as /tmp is also in RAM. Actually does anything NOT in the KNOS folder survive a reboot on a hard disk KNOS system?

I think I'll probably persevere with my scripts then because I can control the details and my wife doesn't have to be trained beyond clicking on the appropriate icon with no risk of the data getting out. Also because I add an automatic time and date to every archive I never overwrite an archive.

[Kevin McAleavey]

When KNOS is copied from a DVD to a writeable file system, everything is in a lockbox just like on the DVD. Nothing survives a reboot other than what is backed up intentionally with the "backup app settings" item on our menu which goes to the stick or other location of your choice, and that's only certain things in the home directory's configuration files.

None of the other directories or files are preserved across a power down even if you were to manage to modify any of the /etc or other locations. Try it for yourself, they'll always revert to the lockbox on power-up no matter what is done. That's all part of what makes KNOS uniquely secure.

And anything that you don't wish to preserve in the "backup app settings" item can be deliberately excluded by adding the location to that ".not.txt" file and it will be prevented from being archived at all.

Do feel free to have a go at those scripts, I'm sure you will have some success with them as long as you're mindful that many Linux locations are not matched in BSD if you're hard-coding path statements in your scripts. That too is for security purposes to prevent Linux malware from figuring our where stuff really is inside KNOS.

[rustleg]

Apr 30, 2012 21:14:18 GMT -5 Kevin McAleavey said:

When KNOS is copied from a DVD to a writeable file system, everything is in a lockbox just like on the DVD. Nothing survives a reboot other than what is backed up intentionally with the "backup app settings" item on our menu which goes to the stick or other location of your choice, and that's only certain things in the home directory's configuration files.

None of the other directories or files are preserved across a power down even if you were to manage to modify any of the /etc or other locations. Try it for yourself, they'll always revert to the lockbox on power-up no matter what is done. That's all part of what makes KNOS uniquely secure.

And anything that you don't wish to preserve in the "backup app settings" item can be deliberately excluded by adding the location to that ".not.txt" file and it will be prevented from being archived at all.

This reveals something to me that I hadn't appreciated and changes what I normally do to backup systems. For all my systems (Windows and Linux) I use a package called "Bootit Bare Metal" from Terabyte Unlimited. I have used this for some years quite successfully as a boot manager and system backup tool. Part of what it does is to take a compressed copy of any partition and save it as a file on another partition. Of course you could use a Linux live CD and a dd command to do this but this requires more knowledge and can be dangerous if a mistake is made so a specific backup tool is very useful. More popular commercial offerings are programs such as Norton Ghost, Acronis True Image, etc.

I was planning to do the same for KNOS and was a little concerned that the imaging process would be long and give relatively large files since the image program doesn't know anything about the BSD file system so can't read the directory structure to avoid imaging free space in the partition. Now I realise all this is completely unnecessary! I don't need an image since the system doesn't change except as regards the settings backup. If the hard disc copy gets corrupted for whatever reason I just need to reinstall from the DVD.

I guess the only issue it to back up the prefs somewhere as I will need to replace it on the reinstalled blank secondary KNOS partition, which is where I find is the easiest place to save it without bothering with USB sticks.

[Kevin McAleavey]

You'll like the way it works with KNOS. No need to back up any of the system, just back up your app settings and whatever data you keep separately from KNOS. That's all you have to worry about. If your "drive" goes four paws to the moon, all you've got to do is break out that DVD, and have it "Make bootable KNOS USB" again. Simply select the "upgrade" option and it will replace the system itself leaving all of your other files on the drive intact! No need to back up the KNOS system itself though, just back up the original iso for the DVD.

Most VM's will also allow you to run directly from that ISO file as well.