-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anders Johansson wrote: > On Sunday 07 October 2007 14:23:50 G T Smith wrote: >> Unfortunately if you can disconnect a resource, you can also reconnect >> something else at the same point, and that could be a security issue. If >> the location is taken it makes it more difficult (but not impossible) to >> hijack. > > No you can't, because linux will only allow you to mount things as a user > when > permission is explicitly given in fstab. Which means the worst they could do > is remount the same resource > > If you think this is wrong, please give a concrete example of how it could be > done
What you say is true if you make the assumption that a workstation is used by a single person only, or network resource access requirements are fairly static on the workstation. /etc/fstab is a good secure mechanism for(workstation based) global resources allocation, and on a single user workstation can be used effectively for access to personalised networks resources as well. While it is there it is nearly impossible to break. There are other environments where the above assumption are not the case, and the /etc/fstab mechanism becomes inadequate. In an environment where people hotdesk rather than people being allocated their own machine in particular, one starts hitting a number of problems particularly in relation to cifs on *NIX (NFS does not really present a problem). If users have personalised resources on cifs shares the administrators life has the potential to get rather interesting in this scenario. Unless one wishes to create an /etc/fstab entry for every possible user of a workstation, which is a potential administrative nightmare with cifs (the maintenance of authentication credentials is a probable show stopper in its own right here), the immediate option is a /etc/fstab based configuration that could reduce administration by using a common home mount point and a mechanism to correctly mount the users resources at that point. However this does present a practical problem in that for this to work the user needs some sort of localised root access. One of Linux's strengths becomes a weakness in that for certain classes of activity one needs a level of access that exceeds that which strictly required. In effect one can find you have to break the security that the /etc/fstab mechanism provides by removing its protection in order to get this to work. In this situation another level of control is required to ensure that some changes are not allowed to happen, (or at least take effect). This is what I mean by there being a possible security issue. The obvious alternative approach of entering via a common server directory and using server access rights to limit visibility presents other issues in a mixed Windows/Linux environment. pam_mount on paper should deal with this issue for common connections. (it also does not require /etc/fstab entries according to the documentation), and is potentially a much neater way of handling a user login to a cifs share as a home directory and disconnecting when the user logs out. However, as at the moment I do not think it can deal with conditional mounts. so in a situation where a user has access to resources not only defined by who they are. but their role in the organisation, and where they are; this on its own is not a complete solution. (Fortunately few have to worry about this one). At the momemt AFAIK a network level of control is only an option with Windows based workstations running with AD or NDS. (IIRC Kerberos was part of the athena project to bring this together for *NIX world a couple of decades ago but to what extent it is now more than authentication mechanism I am uncertain about). In some ways it is fortunate that Samba is most often used to integrate *NIX server resources in a largely Windows environments at the moment. - -- ============================================================================== I have always wished that my computer would be as easy to use as my telephone. My wish has come true. I no longer know how to use my telephone. Bjarne Stroustrup ============================================================================== -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.5 (GNU/Linux) Comment: Using GnuPG with SUSE - http://enigmail.mozdev.org iD8DBQFHCfBRasN0sSnLmgIRAnWSAJ0V3VqkR78Dhic+2aCYVyWZsYrTfACg+kCZ kM1NVOuONWKoJXbUPnfD5yg= =yDrA -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
