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