[mhogomchungu]

It sounds like you are trying to deflect the fault away from TrueCrypt.I looked at the link you provided and i opened a TrueCrypt volume with this command:

[root@mtz zc]# truecrypt ./rrr.img ../ink -p xxx

[root@mtz zc]#

So i opened it from the command line,i looked at the mounted volume and it was also mounted without "nosuid" option and hence the same problematic behavior is there even when TrueCrypt is used from the terminal.

Even when using the CLI component,TrueCrypt automatically does the mounting and hence its TrueCrypt's fault.

The mounting part is not done by a third party script that just happen to be bundled with TrueCrypt,it is done as a core part of TrueCrypt.The "mount" command is set here[1] and executed here[2]. You can walk up the code path to see where the "nosuid" options should have been set but isnt.

Its kind of hard to follow discussions here so if you want to take this further then respond to my email address at mhogomchungu at Gmail Dot com

[1] https://github.com/CipherShed/CipherShed/blob/e8529e95d89d3f...

[2] https://github.com/CipherShed/CipherShed/blob/e8529e95d89d3f...

ps: ciphershed is a TrueCrypt fork.You can look up TrueCrypt's original source code if you dont trust the link i gave as i couldnt find easily taggable TrueCrypt source code online

[simoncion]

There's a reason why I've not included my email address in my HN profile. I'll keep the discussion here. :)

So, if you check the truecrypt manpage [0] (or the code in that GH repo that you linked to) you'll see the presence of the --mount-options option. This allows you to pass along any and all options to mount(8) that you wish to pass along... including nosuid.

The problem you're describing isn't in TrueCrypt the crypto software, it's in its mount(8) wrapper code. TC behaves as block device encryption software, with a wrapper around mount(8) to handle volume mounting, if you want to also mount those volumes. The wrapper around mount behaves exactly as it should... which is that its defaults are the same defaults as mount, and it provides you options (through --mount-options) to change those defaults, by passing those options to mount.

Any other behavior would violate expectations and, thus be grossly incorrect. If you're concerned about others passing you a backdoor flagged with the suid bit, then the TrueCrypt authors gave you a method to mount all TC volumes with the nosuid option set by default. (And, if you're really concerned about the scenario that you outlined, you need a wrapper around mount, anyway, as ALL filesystems that support suid-flagged binaries are "vulnerable" to this "attack".)

TC doesn't need to be changed because of this. :)

[0] http://www.irongeek.com/i.php?page=backtrack-3-man/truecrypt

[mhogomchungu]

Imagine yourself a linux lab operator at a university somewhere and TrueCrypt is installed in the lab computers for students to use to access their TrueCrypt volumes.Most students will expect to have access to TrueCrypt,the GUI application as that is how most people use TrueCrypt.

Now,how exactly can you set up TrueCrypt so that a student could not use it to get root shell as i specified?.

Simple answer,you cant.

Yes,TrueCrypt gives you an option to pass the "nosuid" option.But thats like having a system that requires a password but gives you an option to not provide it with the default behavior being the option of not providing it.

The student who will sit on that computer lab with a TrueCrypt GUI window open will be the one who gets to decide if they want to set the option or not and with the option being off by default,the student will just execute the exploit without changing anything.

I should also say that i am mhogomchungu,the founder of zuluCrypt[1] that does block device encryption and also general purpose mounting with zuluMount,a tool that ships with zuluCrypt and hence i have looked at this problem very closely and for years now and i have closely followed how other FOSS projects reason with problems associated with mount command usage and their implementations to work around the problems.There are also other bunch or wrongs that TrueCrypt is doing and i know this from looking at how things are implemented "from inside" and not how they appear from outside.

Somebody using zuluCrypt to gain root shell and i will take full responsibility for it,somebody use udisks to get root shell access and i will place responsibility fully on udisks and i am fairly certain they will do the same.

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

[simoncion]

> Now,how exactly can you set up TrueCrypt so that a student could not use it to get root shell as i specified?.

Two answers, both simple:

1) You could ask that question about any FS that Linux supports that supports suid binaries. This issue isn't unique to TrueCrypt. This was mentioned upthread by wglb [0], but you brushed him aside with talk of "standard practice".

2) Rename '/bin/mount' to '/bin/mount-real'. Replace /bin/mount with a shell script that checks the desired mountpoint against the mountpoints listed in /etc/fstab (and others, like autofs). If the desired mountpoint is not listed there, add nosuid to the options passed along to /bin/mount-real. Do tell me what I missed here, I only spent two minutes thinking through it.

[0] https://news.ycombinator.com/item?id=8059532

[mhogomchungu]

>This issue isn't unique to TrueCrypt. This was mentioned upthread by wglb [0], but you brushed him aside with talk of "standard practice"

It is not unique to TrueCrypt.It is an issue that arise when a front end to "mount" command BADLY uses it and TrueCrypt BADLY uses "mount" command in a way that leads to privilege escalation as i explained it.

Any front end to "mount" command that uses the command in a BAD way will end up with the same BAD behavior.We are talking about TrueCrypt here and its BAD usage of "mount" command.

If you can use zuluCrypt and gain root shell,i will take responsibility for it and fix the problem.There will be no finger pointing of who is at fault,you got the elevated privileges through my tool and that makes it my problem and it should be me who should fix it.

The elevated privileges were acquired through TrueCrypt and hence its TrueCrypt's fault and TrueCrypt need to fix it or users of TrueCrypt should be made aware of it so that they can guard themselves against.It should be noted that you failed to show they could do so.It should be noted that i mentioned this initially so that those who do TrueCrypt code review will know of it and maybe do something about it.The talk of "its not unique to TrueCrypt" seems to me like an attempt to deflect attention away from the problem as it exists in TrueCrypt.

I did not brush him off,i tried to explain something,maybe you missed it.Let me say it differently.If ext4 has a mount option "--foo" and the "standard practice" is for normal users not to be allowed to use this mount option and you have a mounting tool that chooses to ignore this standard practice and hence a normal user mounts the volume with the mount option and gain root privileges,then the problem will be on your mounting tool and it will be your fault and it will be you who will need to fix the problem.The problem will not be on ext4 file system or on this option.You cause the problem,its your fault.What he tried to do is place fault on linux and make it sound like TrueCrypt is a victim of it and i attempted to place the blame back on TrueCrypt by showing the fault lying in TrueCrypt's lack of following "best practices".I hope that makes sense.

When it comes to mounting in linux,things are done in a specific way and if you create a mounting tool and do things differently,then any breakage or privilege escalations will be on you and it will be your fault.Trying to deflect the problem will only make things bad for you and people will loose trust in your tool.

I am writing this as a person who has spent years thinking about these stuff and write code that implements them and not somebody who has spent minutes thinking about them.

About your second point.What you missed is that you can not do that kind of modification on other people's machines.Making this kind of changes behind user's back should be an offense deserving of being shot.

[simoncion]

I'll engage you once more.

If you ship some software that wraps mount(8), it is expected that that something's defaults will be the same as mount(8)'s defaults. It is also expected that that mount wrapper will permit the user to pass along additional options to mount, so that one can override mount's defaults. Anything else violates expectations and, thus, is incorrect. In other words, TrueCrypt's mount wrapper does things correctly.

Every competent Linux system administrator knows that mount's default options enable setuid binaries, knows the risks of setuid binaries, knows how to pass nosuid to mount, and knows how to write his own wrapper to mount to be pretty sure that only volumes he wishes can be mounted suid. If one is a Linux system administrator, and one does not know these things, then one is, by definition, an incompetent Linux system administrator. Linux is a power tool, not a pair of safety scissors.

I notice that you didn't evaluate either answer to your challenge. Does my second answer contain an error? Why do you have no remark for my first answer?

[mhogomchungu]

I think i did,maybe you missed it.

Let me repeat.

It is a BAD idea to mount a user provided volume with "suid" options. Any mount tool that does this is using mount tool in a BAD way.I think i have said this already.

TrueCrypt is mounting a user provided volume with "suid" option and hence TrueCrypt is using mount command in a BAD way.I think i have already said this.

This is not a problem unique to TrueCrypt.It is a problem that will exist on any mount tool that uses mount command in a BAD way.I think i have already said this too.

Your second answer will solve the problem.It will solve it by filtering out a BAD TrueCrypt mount option.Another way to solve the problem is to modify TrueCrypt source code and add the good option.The modification of the source code is an appropriate approach since it will solve the problem on everybody.

Your second answer will also solve the problem while you insist that "there is no problem to solve as TrueCrypt is doing things the correct way".This kind of talk is commonly known as "double speak".

[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...