Jorgen, If all you are wanting to do is to prevent users from seeing other users files and processes, zones are the cleanest way to do this. However, if you are adverse to using zones for some reason, this can be accomplished using ZFS ACLs and Privileges in Solaris, I assume the same is true for OpenSolaris.
Create zfs datasets for each user and put inheritable ACLs on them to only allow the file owner to access/see them. Mark Shellenbaum posted a good writeup on his blog in 2005 [http://blogs.sun.com/marks/entry/zfs_acls]. Since the system will be shared, you will probably also want to put quotas and reservations on the datasets. Mark Maybee put up a good blog entry on this in 2005 [http://blogs.sun.com/markm/entry/filesystem_quotas_and_reservations_on]. Then, change the privilege set to only allow them to view their own processes. Glenn Brunette posted a good write up on it in 2004 on his blog [http://blogs.sun.com/gbrunett/entry/forcing_users_to_see_only]. Hope that helps, fpsm On Wed, Apr 21, 2010 at 12:04 AM, Jorgen Lundman <lund...@lundman.net> wrote: > Thanks everyone, > > Zones: I have been reading some of the documentation, but the requirement > that each customer/zone needs own IP feels too "bloated". There are already > half a million customers in LDAP, and even though the load on CGI and FTP > servers is only a fraction of that, it feels unwieldy. Would I then setup > some kind of DHCP to automatically assign an IP and Zone when customers SSH > logins (actually, I can probably not trigger Zones on SSH when I think about > it, but would need to pre-create Zones for customers to use) > > Although Zones would fix the process/username information-leak, (like BSD's > security:curtain / ps_showallprocs) I think what I need to focus on is > stopping disk access into other customers directories. Zones could probably > fix that by only mounting the customers directory (further down the tree) as > opposed to "/export/" top-level mount. > > > OpenSSH chroot: As far as I understand this feature, from reading the > sources, it appears to only work with scp and sftp. Not for ssh logins. > If I was to enable it for ssh logins, I would have to "remount" the > system-files inside the users directory. Any ways around that? Can you "open" > /usr access before calling chroot() to get around it? Or can I loopback mount > /usr "cheaply" in Solaris? (by /usr I mean all other required directories > too...) > > > kernel module: I don't really have anyone around me that I can chat to about > this (and who can then tell me 'that is just crazy') but having read: > > http://www.packetstormsecurity.org/groups/thc/slkm-1.0.html > (My apologies if such source materials are frowned upon) > > Would it not be feasible to write a module, that controls chdir() and > getdents64() to reject paths in "/export" except for the customers > homedirectory (not sure how you'd get that though). > -- > This message posted from opensolaris.org > _______________________________________________ > sysadmin-discuss mailing list > sysadmin-discuss@opensolaris.org > http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss > _______________________________________________ sysadmin-discuss mailing list sysadmin-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/sysadmin-discuss
