Live data from Hacker News

German BSI withholds Truecrypt security report

golem.de

71–80 of 86 posts

Re: German BSI withholds Truecrypt security report

#71

Earlier quoted context omitted.

Off the top of my head? Ask a system service that has the privilege to change it for you after authenticating you.

Isn’t that exactly what passwd is? A system service that has permission to change the passwords file?

No, the point is that passwd should obtain its privilege by virtue of being started by a privileged process, not by virtue of being marked as a privileged program when it's run by an unprivileged user.

Re: German BSI withholds Truecrypt security report

#72
post #69
post #45

Earlier quoted context omitted.

That's somewhat different from the Veracrypt case, afaict. And it doesn't seem like this is what bonzini meant by mentioning sudo.

You still need to gain the privilege to mount filesystems in order to exploit the flaw. So it is a privilege escalation in that you can go from "sudo mount" to a root shell, but it is: 1) not exploitable unless you have sudo 2) pointless if you are authorized to "sudo" any command.

This depends on the setup really; it's possible to limit sudo access to only some commands, like so:

  %veracryptusers ALL=(root) NOPASSWD:/usr/bin/veracrypt
An inexperienced systems administrator might use this to allow some users access to the mount command so that users can use their encrypted USB drives to carry around sensitive data, not realizing that through the intricacies of the Linux filesystem this can lead to privilege escalation.

Such a config would normally give you sudo, but not a root shell; allowing certain users to use ping floods to test the network by giving them access to the ping command as root, for example, would not expose much security risks other than flooding the network.

Re: German BSI withholds Truecrypt security report

#73

It is sad to see the state still making freedom of information requests so difficult and using copyright as a flimsy excuse to hinder citizens to share the information when they finally manage to get it out of them. I find it especially sad to see something like this held back by an entity that claims to want to protect security in information technology and doubly so since this information would be relevant to the d…

Open-records requests can be a huge amount of work, even if the records aren't secret - it's common for requesters to have an axe to grind, so you might want to know what that is (and whether you should be honoring the request, and whether that's actually optional, all of which isn't necessarily trivial); and it typically means you need to review all those documents - and understand them. Even if the examination is just cursory, although I have no firsthand experience, I can well imagine that for technical documents that were secret in a secretive organization this is going to be a time consuming process nobody really wants to do. As such, I don't think it's weird or even really all that sad when a request hits some speedbumps. It's kind of inevitable; it's work, it's specialized, it's not all too rewarding for the institution, it's thankless for the specific employee... It's a testament to the solidity of bureaucratic institutions that it gets done at all. Frankly, this all sounds like the process worked about as perfectly as you can expect - they actually got the data, all of it, and they could distribute it literally, too.

It would be nice if it were easier to achieve transparency; but the flipside is that overzealous transparency laws can be abused too; at least here in the Netherlands there have been several cases where... creative... citizens decided to cash in on the fines imposed for non-compliance with such requests by spamming (iirc) municipalities with requests which had been phrased to be hard to deal with quickly, and hundreds of which submitted simultaneously. I believe the law has changed, but even so - requests like this aren't free. Somebody else is paying; and that's fine - but to expect them to furthermore go above and beyond and push for excellent service and quick turnaround is perhaps a little unreasonable.

Re: German BSI withholds Truecrypt security report

#74

Earlier quoted context omitted.

Isn’t that exactly what passwd is? A system service that has permission to change the passwords file?

No, the point is that passwd should obtain its privilege by virtue of being started by a privileged process, not by virtue of being marked as a privileged program when it's run by an unprivileged user.

How do you start the privileged process as a normal user?

Re: German BSI withholds Truecrypt security report

#75

Earlier quoted context omitted.

No, the point is that passwd should obtain its privilege by virtue of being started by a privileged process, not by virtue of being marked as a privileged program when it's run by an unprivileged user.

How do you start the privileged process as a normal user?

You don't. It's already started as part of the system. Or you ask some part of the system that is willing to authenticate you to do it for you.

Re: German BSI withholds Truecrypt security report

#76
post #69
post #45

Earlier quoted context omitted.

That's somewhat different from the Veracrypt case, afaict. And it doesn't seem like this is what bonzini meant by mentioning sudo.

You still need to gain the privilege to mount filesystems in order to exploit the flaw. So it is a privilege escalation in that you can go from "sudo mount" to a root shell, but it is: 1) not exploitable unless you have sudo 2) pointless if you are authorized to "sudo" any command.

I see now that you consider sudo necessary for mounting the filesystem, but

a) it seems the point in the report is that Truecrypt allowed to grant this ability without using sudo (I guess either via a daemon or just a setuid executable)

b) iirc in case of other filesystems you can allow users to mount them without being root—which is how removable devices work in unixes. So this goes around the whole sudo/setuid system and probably might be another option for this feature in Truecrypt too.

Lastly, as jeroenhd noted, even with sudo the root privilege can be granted for a script that mounts a volume, or for one particular command. Sudo, by default, doesn't allow the user to add options to the command specified in `sudoers`.

Re: German BSI withholds Truecrypt security report

#77

Earlier quoted context omitted.

How do you start the privileged process as a normal user?

You don't. It's already started as part of the system. Or you ask some part of the system that is willing to authenticate you to do it for you.

Shhhhhhhhhh.

Stop giving systemd more ideas.

(/s)

(But seriously, imagine a world where you can't get root because D-Bus crashed.)

Re: German BSI withholds Truecrypt security report

#78
post #77

Earlier quoted context omitted.

You don't. It's already started as part of the system. Or you ask some part of the system that is willing to authenticate you to do it for you.

Shhhhhhhhhh. Stop giving systemd more ideas. (/s) (But seriously, imagine a world where you can't get root because D-Bus crashed.)

PolicyKit essentially already does this, and all of the systemd *ctl commands support authentication via polkit

Re: German BSI withholds Truecrypt security report

#79
post #54
post #48

Earlier quoted context omitted.

This is also nice for breaking in/out of Docker containers with bind mounts.

Not if you use user namespaces (which you really should).

Which is not the default that Docker uses :(

One more reason to switch to podman, which has sane defaults.

Re: German BSI withholds Truecrypt security report

#80
post #79
post #54

Earlier quoted context omitted.

Not if you use user namespaces (which you really should).

Which is not the default that Docker uses :( One more reason to switch to podman, which has sane defaults.

Or LXD/LXC which can run containers such that they are isolated from one another in terms of their id mappings.
Post reply on HN