encription software for Linux and Windows / Alternative for TrueCrypt ?
Linux - SecurityThis forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
How hard is it to download an executable and run it on a remote system (assuming there's not firewall protections prohibiting it)?
Very hard. And firewalls are the norm these days. How would you run a program on my computer, if you control a website I visit? Statistically, this is possible (zero day exploits), but how does it make a difference if I use truecrypt for my data? Again, not truecrypt's fault.
Quote:
I don't buy this assumption that it's the program he wrote that is flawed.
I deduced this from his description of what the program does: It runs its first parameter as a program. /bin/bash in his example. With c knowledge, very easy to write. And he deliberately put the executable with suid bit in file flags in the container. That's the whole trick, and this trick would be possible with many filesystems. Udev is smarter these days - my ext2 usb stick is mounted with nosuid - but you are blowing up the proportion of "truecrypt's fault" a bit. A cautious user could still open the container with "--filesystem=none" and mount with "nosuid,nodev".
Quote:
Originally Posted by mhogomchungu
If there is a linux based public computer with TrueCrypt installed for the public to use to access their TrueCrypt
volumes,then through this trick,any user can get root access on that computer.
Let me rephrase this a bit: If there is a linux based public computer with /bin/mount installed for the public to use to access their unencrypted volumes,then through this trick,any user can get root access on that computer.
Very hard. And firewalls are the norm these days. How would you run a program on my computer, if you control a website I visit? Statistically, this is possible (zero day exploits), but how does it make a difference if I use truecrypt for my data? Again, not truecrypt's fault.
I don't think you understand the point I made and took it out of context with zero day exploits. You're very mistaken if you think most computer firewalls (including servers) are strict prohibiting outbound traffic. Inbound, sure, but not outbound.
I'll reiterate. This can be mitigated by changing the default options truecrypt uses to mount the filesystem. It is entirely truecrypts fault if an executable can be launched from a truecrypt mounted filesystem and gain root without normal authorization. That is what is called an exploit.
You're very mistaken if you think most computer firewalls (including servers) are strict prohibiting outbound traffic.
I fail to see how outbound traffic is relevant here: The task is "get an suid binary to run on my computer". Downloading mhogomchungu's container and executing the "owned" program by hand does not count - everybody can infest their containers by downloading something randomly from the oh-so-trustworthy internet and running it. That's how most private computers get infected - by user naivety or stupidity.
The rest of your post: Fair point. I tried different scenarios with normal unencrypted filesystems and it seems that consolekit/polkit forbids suid option with removable devices. Which is good. A normal user cannot run mount directly with a filesystem not in fstab. Truecrypt developers could have done better by using nosuid and nodev by default for internal devices, and using consolekit/polkit/systemd for removable devices. These forbid suid anyway.
mhogomchungu constructs two scenarios which I think should be treated differently:
1. Truecrypt usage on your own workstation. Cryptsetup-luks should be the software of choice, but maybe container exchange with windows is needed. Truecrypt asks for root/sudo password, which means unauthorized users cannot use truecrypt at all. You know the passwords, and if you care about suid/dev, you do the following (as root):
2. Truecrypt on a public computer accessible to anyone. This is not responsibly possible. Truecrypt asks for root/user password and tries to use sudo or root directly. Without password, truecrypt is not usable at all. I hope noone is stupid enough to configure a public computer in that way. Users could just become root directly, without using truecrypt and an own suid binary in a container.
Last edited by cepheus11; 02-01-2015 at 05:57 AM.
Reason: mountopts can be passed to truecrypt directly, only one command necessary
I fail to see how outbound traffic is relevant here
Outbound traffic was defending the point that it is not hard to download a remote binary on a system that has already been remotely compromised. The original scenario I painted was a system that was remotely compromised through other means and then truecrypt was the avenue to exploit for root access (in an unlikely scenario that a truecrypt volume was mounted at the same time as the remote compromise).
Quote:
Originally Posted by cepheus11
The rest of your post: Fair point. I tried different scenarios with normal unencrypted filesystems and it seems that consolekit/polkit forbids suid option with removable devices. Which is good. A normal user cannot run mount directly with a filesystem not in fstab. Truecrypt developers could have done better by using nosuid and nodev by default for internal devices, and using consolekit/polkit/systemd for removable devices. These forbid suid anyway.
mhogomchungu constructs two scenarios which I think should be treated differently:
Other users' scenarios or opinions aside I was defending that the issue posted by the first post of mhogomchungu: was that root access being able to be gained from a truecrypt mounted volume was a bug in truecrypt. Others were defending that it was not truecrypt's problem. I disagreed and drove home the point that it was an exploit that used truecrypt mounted volumes; hence it being a root problem with truecrypt.
I agree with your assessment, cepheus11, that there are better ways to secure your data and that they should be used instead of depending on something no longer maintained. Best practices should be adhered and that includes not accessing anything of importance from a public computer.
a system that was remotely compromised through other means and then truecrypt was the avenue to exploit for root access
Okay I see. I don't know the rationale of the truecrypt developers or if they even thought about that, but "nosuid,nodev" as a default would have been better indeed.
I was critisizing mhogomchungu's exploit because it depended on the user to download his volume from the internet and executing a program from it. I could provide a volume with the same content unencrypted, with the instruction:
Code:
losetup /dev/loop0 /path/to/file
mount /dev/loop0 /path/to/mountpoint
And then as a user:
Code:
/path/to/mountpoint/owned
And it would work in the same way, so one could say "losetup/mount is broken because suid is default".
Last edited by cepheus11; 02-01-2015 at 11:14 AM.
Reason: drop root rights before "owned"
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.