Re: untrusted translators
At 20 Mar 2005 20:15:03 -0800, Thomas Bushnell BSG wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > Following untrusted translators in the filesystem is a real security > > hazard. > > Can you say more about a specific losing scenario? I did my level > best to make sure that following translators doesn't give away any > privs. What's the problem? A simple example of problem is a translator with an infinite file hierarchy. That can be done in the file system using finite space: the root directory contains a directory, DIR, with inode #3, which contains a directory, DIR, with inode #4, which contains a directory, DIR with inode #5, etc. Any process trying to list this part of the VFS will end up in an infinite loop. This would affect the program which updates the locate database, users who run `find /', etc. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: untrusted translators
At 20 Mar 2005 20:15:03 -0800, Thomas Bushnell BSG wrote: > > Marcus Brinkmann <[EMAIL PROTECTED]> writes: > > > Following untrusted translators in the filesystem is a real security > > hazard. > > Can you say more about a specific losing scenario? I did my level > best to make sure that following translators doesn't give away any > privs. What's the problem? It's not about giving away privileges, it is about tricking the user into doing something he doesn't want. Here is one particularly nasty example. User: $ settrans /home/user/tmp/foobar/.../screw\'em /hurd/firmlink /root $ [create some really big useless files in /home/user/tmp/foobar] $ [go on vacation] Administrator: # [mmmh, why is there so little disk space...] # rm -fR /home/user/tmp/foobar/ # [don't notice anything for a while...] # ARGH! Or just create some really deep (infinite) virtual directories and let the find operation of the location database go run mad on it in a cron job. Now, we have our own temp reaper. And a tmp reaper would be trivial if you would hack rm to have a "--do-not-follow-translator" option. But I believe that is not good enough. The reason is that 1) It is unfeasible to change all programs that traverse filesystems, or just follow untrusted paths. It may not even be possible to easily find out which programs do that. You would have to audit each and every package, and modify it either to be safe by default or to allow safeness options to be set via the environment or command line options. A huge task, given the number of software out there. 2) Even if you were to undertake it, it would _still_ be wrong. Programs should be secure by default, not insecure by default. This is especially true because: 3) This is the POSIX personality of the Hurd, and people will have certain expectations about how to be secure. It's already difficult enough to make people security-aware. Complicate the attack scenarios, and you will quickly lose people's attention. Unix security is already difficult enough without the Hurd's extensions. But then there is: 4) There is just a huge amount of literature that says how POSIX like system work, starting with something like Richard Stevens, and ending with web-tutorials, training programs, etc. This literature describes what you can expect and what you don't need to expect, but it is usually not Hurd-aware (and realistically, that's not going to change. Even if the Hurd were an instant success it would take decades to replace all books in all libraries etc). Millions of people are teached according to this literature, and if they'd start to use the Hurd they wouldn't know what had hit them. Everything would look like they know it, but what we see as useful extensions would appear to them _first_ as horrible invisible pit falls. In other words: The "insecure by default" is like setting a trap. It just begs for someone to forget about our extensions and do a wrong command that would be perfectly fine on Unix, but wrecks havoc with your files or other things on the Hurd. I have posted a suggestion to fix this a long time ago, but can't find the mail right now (maybe I never sent it?). The solution would be to always open nodes with O_NOTRANS, and if the translator bit is set, there is a user ID check. If the user ID belongs to a trusted set, which by default is "0-XXX,myself" where 0-XXX is the range of system user IDs (this would be 0-999 on my system, I think), then the translator is followed. Otherwise it is not followed, unless the user explicitely specifies a new flag O_TRANS. The set of trusted user IDs could be set via an environment variable, which would work very much like LD_LIBRARY_PATH. This variable would be cleared for suid programs. Thanks, Marcus ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: heads up
Thomas, we can aruge all we want, for days and years. But the fact is that the only way to prove that you design actually works is to implement it. I can't disprove that it won't work, since that is theoretically impossible. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: heads up
"Alfred M. Szmidt" <[EMAIL PROTECTED]> writes: > Thomas, we can aruge all we want, for days and years. But the fact is > that the only way to prove that you design actually works is to > implement it. I can't disprove that it won't work, since that is > theoretically impossible. I'm not trying to prove anything. I'm glad that a few people here have understood what I've been saying and getting some of the point; when people have the time to work on it, I'm glad to help further. It simply seems as if you don't understand what I've been describing, which is no shame, but then, please let me continue the conversation with others and without attacking me for it. Thomas ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: untrusted translators
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > Now, we have our own temp reaper. And a tmp reaper would be trivial > if you would hack rm to have a "--do-not-follow-translator" option. > But I believe that is not good enough. The reason is that So my response in the past has been "filesystem traversers need to know about this new feature." You are probably right indeed, however, when you say: > 1) It is unfeasible to change all programs that traverse filesystems, >or just follow untrusted paths. It may not even be possible to >easily find out which programs do that. Moreover, we have to re-program users, not just programs. So even if we could fix every program, we can't fix all their users: > 3) This is the POSIX personality of the Hurd, and people will have >certain expectations about how to be secure. > I have posted a suggestion to fix this a long time ago, but can't find > the mail right now (maybe I never sent it?). The solution would be to > always open nodes with O_NOTRANS, and if the translator bit is set, > there is a user ID check. If the user ID belongs to a trusted set, > which by default is "0-XXX,myself" where 0-XXX is the range of system > user IDs (this would be 0-999 on my system, I think), then the > translator is followed. Otherwise it is not followed, unless the user > explicitely specifies a new flag O_TRANS. Yes, that works; having it done through an environment variable makes it fairly easy for users to overcome it when they want. I'm not sure this is the right fix, but it looks like it would work well. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: untrusted translators
At 21 Mar 2005 06:39:31 -0800, Thomas Bushnell BSG wrote: > > I have posted a suggestion to fix this a long time ago, but can't find > > the mail right now (maybe I never sent it?). The solution would be to > > always open nodes with O_NOTRANS, and if the translator bit is set, > > there is a user ID check. If the user ID belongs to a trusted set, > > which by default is "0-XXX,myself" where 0-XXX is the range of system > > user IDs (this would be 0-999 on my system, I think), then the > > translator is followed. Otherwise it is not followed, unless the user > > explicitely specifies a new flag O_TRANS. > > Yes, that works; having it done through an environment variable makes > it fairly easy for users to overcome it when they want. One could always have a special value like "@all" mean that all uids are acceptable. This would be what the current default is. > I'm not sure this is the right fix, but it looks like it would work > well. Independent of any argument about what a reasonable default is, I think that being able to configure which translators to follow based on the user id of the underlying node is a pretty basic security feature that's quite desirable. And an environment variable that is understood by the glibc core seems to be the appropriate mechanism for that. I don't fancy the fact that my suggested default includes a "system range" of user IDs. One idea is to have the default (without any environment variable set) to be "@all"[1], and then just make sure that distributions ship with an appropriate default environment set up (ie, Debian would set it to 0-999,@myself) in /etc/profile or whatever. You would still have to ensure that programs running early at boot time would also see such an environment. For suid exec's, they could inherit this variable from their parent filesystem, which will provide them with what they consider to be a secure default (usually its own). This seems to be slightly more flexible than what I proposed in my last mail. For example, if you set up an active filesystem, it will inherit your "friend list", and pass it on to suid binaries started from that filesystem. Sounds fine to me. Thanks, Marcus [1] Such a solution would have the problem that if you mess up your configuration, ie something wents wrong with setting up the environment, you get an insecure default. So, if you are paranoid, like me, you would want to default to "root=0,@myself", and nothing else, instead of "@all". The important part of the proposal is that it does rely on the distribution and system administrator to figure out the range of system UIDs. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Re: untrusted translators
Marcus Brinkmann <[EMAIL PROTECTED]> writes: > I don't fancy the fact that my suggested default includes a "system > range" of user IDs. One idea is to have the default (without any > environment variable set) to be "@all"[1], and then just make sure that > distributions ship with an appropriate default environment set up (ie, > Debian would set it to 0-999,@myself) in /etc/profile or whatever. Better is to enable it to key off gids too, I would think. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
Your eBay account could be Suspended
>> Dear eBay member, We at eBay are sorry to inform you that we are having problems with the billing information of your account. We would appreciate it if you would visit our eBay Billing Center and fill out the proper information that we are needing to keep you as an eBay member. If you don't comply until the 15st April 2005, your eBay membership may be suspended, or even deleted. Click here to complete our web form. As outlined in our User Agreement, eBay will periodically send you information about site changes and enhancements. Visit our Privacy Policy and User Agreement if you have any questions. Thank you! Copyright © 1995-2005 eBay Inc. All Rights Reserved. Designated trademarks and brands are the property of their respective owners. eBay and the eBay logo are trademarks of eBay Inc. ___ Bug-hurd mailing list Bug-hurd@gnu.org http://lists.gnu.org/mailman/listinfo/bug-hurd
