I would like to password-protect or encrypt a single directory of mine.

There seem to be so many different solutions, so many different packages, and so many different methods that can supposedly do this, but all I need is something simple and clean, preferably one built into the stock Slackware.

I'm running Slackware64 v13.1. My partition scheme is as follows:

As you can see, I am not able to encrypt my /home partition since I do not have one. I prefer to have a single partition for everything on root (I spent months working on a partition scheme, and eventually I fell back to this).

On Mac OS X, the user is able to create a .dmg disk image and require a password for mounting. I am not sure if the data is actually encrypted, but this is a wonderful solution. Hopefully there is something like this for Slackware.

I ask you of the Slackware community because I want to know the solution (out of the many available) that a Slackware user would enjoy: something clean, light, without excess, and excellent in function. I don't want some huge program that does every possible security measure there is. All I want is the ability to password-protect any directory I create (like ~/important or ~/crypt) so the contents cannot be viewed by anyone unless they know the password.

Thanks for any help

You can create an encrypted container with TrueCrypt. It's not preinstalled, but available on SlackBuilds.org

http://slackbuilds.org/repository/13...tem/truecrypt/

Well, you could run LVM so that you could just make an encrypted /home volume. That would be a major PITA for you.

Try "man mount" and search for "THE LOOP DEVICE". Then read this, which (despite its age) should give you an idea on what to do.

Try encfs.

This is something which interested me as well. I wanted to encrypt parts of my home directory. In the end, I chose encfs. To integrate it with the desktop, I wrote a little script that would access my encfs password from kwallet. On logging in, I only needed to start kwallet and my encrypted directories would become automatically accessible. Note that I was using kwallet in any case for storing kmail and konqueror passwords so this was the best of limiting the number of times I had to enter a password every time I logged in.

Now for the bad news. A while back encfs showed itself to be a bit unreliable. If I had not done backups of my data, I would have suffered some serious data loss since it would corrupt the xml file needed to decrypt your data. I started a thread about it: Encfs on current. I stopped using encfs at that time and have not found a replacement yet. As I understand the problem has been fixed for Slackware 13.1, but I am wary of going back. If you have unencrypted backups of your data elsewhere, it is probably suitable for your requirements, but otherwise I can't recommend it.

I would be interested in hearing other ideas on how people encrypt part of a partition which can be accessed as transparently as possible to the user.

Very interessting indeed. I have little personal experience with encryption of whole folders, but I just thought I would comment a little on password protected solutions.

A bad solution would be to make a folder that belong to a different user. You would have to su to that user and supply this users password, or login as root to access this folder. But there is no "physical" restrictions. All the restrictions would be in the UID, which in turn can easily be bypassed with physical access to the computer. So this method is more a "security by obscurity" then protecting your files.

Going on what Dinithion said, an even simpler non-encryption solution would be making a directory accessible only to members of a certain group and then put anyone who is to have access to the data in that group. But as stated, with physical access it would be trivial to access the data.

agi93,

Check out this article: Protecting directory trees with gpgdir.

If you're not already using GPG (GNU Privacy Guard, the GNU version of Pretty Good Privacy) to check file integrity and authenticity when you download them, you should be! If you are using GPG, then gpgdir looks pretty good.

I haven't used pgpdir, though, so take my recommendation with a grain of salt.

Regards,

Truecrypt looks like its exactly what I need. It has a feature to create a .tc file which can be mounted and used to store other files. This is just like the .dmg system on OS X.

gpgdir looks pretty interesting, too.


About LVM, I had an LVM partition scheme with all sorts of directories (/, /home, /var, /usr, /opt) separated just before I went back to the one-partition-for-root system I have now. Oh well. It's good to know LVM can do that just in case I want to encrypt /home on future systems.

Messing with users and groups looks like a fun way to make file access more roundabout for someone, but there still is that physical access problem, and root can easily override any obscurity/security that provides.


I'll go try TrueCrypt and let you know if I have problems or if it works alright.

Edit: Truecrypt is awesome! I just created a 4GB crypt.tc file which I mount in /mnt/crypt when necessary. Thanks!

Also, sbopkg cannot properly download truecrypt. This is because the source link on slackbuilds.org leads to a download page instead of the actual source. This is also the case with dzen2. As a result, I had to build both manually with the SlackBuilds. This is not too much of a problem, as sbopkg still recognizes the package and will check for updates (I hope), but there should be some fix for this. Perhaps chess can add a feature to sbopkg in which a failed md5sum check would provide an option for the user to visit the download site with the links browser and download the source manually. Sbopkg could then have that source sent to /var/cache/sbopkg and recognize its download, allowing for the continuation of the build.

Until something like that happens, manual building also works.

Actually, sbopkg handles stuff like that quite well, with some user intervention.

Before building running the slackbuild, take a moment and look at the sbopkg menu. There's an option to edit the .info file for that particular package. That's where you can input the correct download link.

Regards,

AlienBOB has a TrueCrypt build script on his site, along with the source, if you can't get the SlackBuilds site to work.

Another plus for TrueCrypt is that the .tc container files are easy to transfer among systems, and TrueCrypt is cross-platform.

Sometimes there really is no download link though. With truecrypt I had to check a license agreement box, select the Mac/Linux version from a dropdown menu, and then click download before it work work. Gah! Why can't they just have a simple ftp site with a note that says "By downloading any of these files, you accept this license agreement: ...".

That's cool though. Maybe I'll use that to point to Eric's source instead next time.


Also, I wish Eric would organize his repo at the top level by Slackware version. That way, I could mirror 13.1/ only (or whatever is relevant to my system at the time) without downloading all these extra files that don't even apply to my system.

What happens with dzen2 and truecrypt are actually very different but 0.33.1 does trip over dzen2. That's fixed in svn, though. And, yes, after you get it installed, sbopkg will handle it as any other SBo package. Just to note: you can download the source to your $SRCDIR and then run sbopkg as normal. But downloading it anywhere, setting everything up and, running the SlackBuild directly works too, of course.

As far as truecrypt, though, there are limits to the upstream... eccentricities... (must be polite) that sbopkg can work around. If sbopkg doesn't have a url to work with, it doesn't have a url.

As far as the browser-to-homepage option, we'll think about that (or I will anyway). There are reasons for the md5 to fail that wouldn't be solved by going to a homepage and, even after going to a homepage, you'd likely have to change things like the md5sum or version number or whatever. So it may not be doable or may not be done, but might. Thanks for the suggestion.

Also, if you encounter problems like dzen2 and truecrypt, please report it to the googlecode tracker or, if you aren't or don't want to be google-ized, drop by #sbopkg on freenode and report it there. We're more likely to be sure to know about it if you do.

I'll start doing more bug reports when I encounter this kind of thing. Thanks so much to all the sbopkg maintainers for putting so much care into their program. It's really a beautiful piece of software

I also hear TrueCrypt is great for cross-platform use.

I use EncFS and have never had any problems with it. It has the advantage that it behaves more like a regular file system and not like a loop back filesystem, so I can incrementally back up individual files instead of one big file.