[Dylan16807]

You seem to be missing a critical detail here. Using mount unsafely requires you to already be root. Mounting a volume with truecrypt does not[1] require you to be root. But it invokes mount for you, as root, in an unsafe way.

[1]AFAIK, based on the video, and knowing that it doesn't require admin on windows

[simoncion]

From what I've seen on Linux, TrueCrypt is run as root. The two other ways it could do mounting are:

1) Use FUSE's ability to (as a non-root user) mount user-readable devices in a user-owned directory.

2) Do as Docker does and talk to over a socket to a daemon running as root.

From what I've seen the official TrueCrypt software does neither of these things. What video are you talking about? Perhaps I missed something?

On Windows, it's not uncommon for an unprivileged process to talk to a root-equivalent Service to perform privileged operations.

[Dylan16807]

Nevermind, I tested myself and properly read the post[1] after getting some sleep. Truecrypt does need root and he gave sudo rights for it. Otherwise it asks for a suitable password when used to mount.

So this isn't a security flaw, this is a feature request for non-root mounting.

Except you can already use FUSE so I'm not sure what the complaint is at all. Don't let people run commands as root that weren't designed for it.

Sorry about the noise.

[1] http://vinicius777.github.io/blog/2014/07/14/truecrypt-privi...

[mhogomchungu]

You need root privileges to gain access to a block device.

You need root privileges to gain access to kernel cryto and other kernel managed resources.

For a project to be usable to normal users,it need to be assessable to normal users and hence it need to walk a fine line between being privileged and being not privileged as it need to exist on both side of the fence.

As far as TrueCrypt is concerned,any person who sets up TrueCrypt for somebody else to use end up setting up passwordless sudo for it and this opens up the discussed problem.It is a security issue in a sense that TrueCrypt does not take into account its privileged position when it interfaces with mount command.You can nitpick on the passwordless sudo part but one way or the other,TrueCrypt expect to be run privileged and sudo is the easiest path but pick any other method you prefer.

FUSE will give you a workaround as far as mounting is concerned but you will still need root privileges when invoking kernel crypto or other kernel managed infrastructure. FUSE also solves a mounting problem but a different one.

There are 3 different "techniques" that can be used to allow a normal user to do mounting operations and i discussed them here[1] as the first FAQ entry.

This will be a security issue if it happened to udisks or anybody else i know.Maybe linux users of TrueCrypt are a completely different audience when it comes to this kind of privilege separation issues.

[1] https://code.google.com/p/zulucrypt/wiki/FAQ

[Dylan16807]

Which means providing a program or service that is meant to be invoked by non-root users, and will perform limited trusted behaviors on their behalf.

This is a feature request, not a security flaw. It's a pretty glaring gap that should be filled, but it's not a mistake.

[mhogomchungu]

TrueCrypt GUI is designed to be invokable by non-root users.I can not say "meant" because only TrueCrypt developers know what they actually mean with anything.

Start TrueCrypt GUI from a normal user account and TrueCrypt will attempt to self elevate internally using a functional sudo setup.This shows a deliberate attempt by TrueCrypt to be usable by normal users.It just leave it up to the user to setup sudo for it.

Setup sudo to require a password and TrueCrypt will get stuck on its password prompt(bug) and hence passwordless sudo setup will be the only way to go when setting up TrueCrypt to be used by normal users or,alternatively,starting up TrueCrypt from root's account for normal users(not very practical/convenient).

With both ways,the discussed problem will be there.