Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

ECryptfs Security Audit

defuse.ca

Post reply on HN
Print view View original

61–66 of 66 posts

Re: ECryptfs Security Audit

#61

Post by mhogomchungu »

simoncion wrote: post #56
mhogomchungu wrote: post #53

Earlier quoted context omitted.

>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 wil…

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…

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

Re: ECryptfs Security Audit

#62

Post by mhogomchungu »

Dylan16807 wrote: post #59
simoncion wrote: post #57

Earlier quoted context omitted.

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…

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…

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

Re: ECryptfs Security Audit

#63

Post by Dylan16807 »

mhogomchungu wrote: post #62
Dylan16807 wrote: post #59

Earlier quoted context omitted.

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…

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 se…

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.

Re: ECryptfs Security Audit

#64

Post by [deleted] »

mhogomchungu wrote: post #62
Dylan16807 wrote: post #59

Earlier quoted context omitted.

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…

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 se…

[deleted]

Re: ECryptfs Security Audit

#65

Post by mhogomchungu »

Dylan16807 wrote: post #63
mhogomchungu wrote: post #62

Earlier quoted context omitted.

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 se…

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.

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.

Re: ECryptfs Security Audit

#66

Post by wglb »

hadoukenio wrote: post #27
tptacek wrote: post #4

Earlier quoted context omitted.

EcryptFS and Truecrypt are very different systems. Truecrypt is simulated hardware encryption. It creates a virtual encrypted hard disk, which your operating system can more or less treat like an ordinary hard disk, but for the kernel hooks Truecrypt adds to lock and unlock the disk. EcryptFS is an encrypted filesystem. Unlike Truecrypt, which encrypts individual disk blocks, systems like EcryptFS encrypt and decrypt…

That's a great explanation. Thanks for that. Now I'm curious about why it's so locked down at Matasano... what are the main threats to need full-disk encryption and then multiple encrypted containers per project? I should have explained my reasoning for originally choosing ecryptfs. I find it really convenient doing a backup of ecryptfs' cipher-text. Since it's simple files, an rsync will do. If I wanted to backup vi…

First protection is against laptop being stolen and the hazmat is exposed.

Separate vaults are useful if you have multiple clients, say, and you are doing pen tests. While you are working on one, the others are not unlocked.

Post reply on HN