Well i suppose if an application only gets the common rights of itself and the user that's executing the application it would help a lot to reduce security problems. It might require us to automatically enforce certain (default?) rights onto applications.. because most programmers, unfortunatly, do not take the time to limit an applications rights... If an application uses plugins, and has full rights.. and then gets to impersonate someone.. a plugin would get full rights to that person's account.. That's a bit scary.. we can't assume that all users are expert users.. that faulty assumption is one of the roots of most security problems in modern day operating systems.. So the default should be 'completely locked down', and an expert user could override it if for some reason he'd want to... (but applications shouldn't be able to simply do that.. basically only a handfull applications that came with the OS that have the right to do so)
As for .net applications requiring it, there's nothing stopping us from more or less sandboxing .net applications (putting a layer in between) and doing our own thing for the rest of the OS... (not that that's an easy thing to do) It would definitely help if we only use impersonation at the "logging in" level, physically behind the machine and remote. Basically only a handfull of applications would have the right to 'impersonate'.. (and even fewer would have the right to modify that right ;) I'm just "thinking out loud" here. On Nov 12, 2007 7:16 AM, Jonathan Chayce Dickinson <[EMAIL PROTECTED]> wrote: > [Jonathan Dickinson] > There is a /slight/ problem with that. Let's look at it at the most basic > and fundamental viewpoint. We have two users joe and jack. Joe and jack use > NFS to access their home directories when they are out of the office. They > obviously need to use the same username and password as their local account > (or even better, it is as transparent as network domains are. Once you are > logged in you never have to log in again: all your services are > automatically activated - which is AFAIK impossible without impersonation). > Without impersonation Joe could see Jack's home directory. How could we > solve that? Make an API that allows us to authenticate a user through custom > code: > > Joe logs into NFS -> NFS knows where he can and can't go. > Same for Jack. > > That is peachy, until you consider a few things. First of all, you have > duplication of security data. We are storing access rights in both NFS and > VFS. Bad if they go out of sync for some reason. Furthermore, once we write > the security code for VFS we could copy-n-paste it into NFS. Also bad, what > happens if we fix a security bug in one and not the other (one of the > fundamentals of OOP). > > I know impersonation might be hydrocarbon technology, but how to we fix it? > What can we do instead? Also consider a simple corporate mail website. We > could authenticate a user as TheRootMailUser and make sure that we don't > allow them access to each-other manually. Or we could log them as themselves > and be rest-assured that the user only has access to one directory on the > VFS. Any ideas? ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ SharpOS-Developers mailing list SharpOS-Developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/sharpos-developers
