Hello list. I would like to get your opinion on what is a safe multi-user environment. The scenario: We would like to offer to some customers of ours some sort of network backup/archive. They would put daily or weekly backups from their local machine on our server using rsync and SSH. Therefore, they all have a user account on our server. However, we must ensure that they would absolutely not be able to access any data of each other at all. What is the "best and safest" way to do so? Regular UNIX permission settings? File system ACL's? User jails? Restricting commands in their path environment? Or would it even make sense to encrypt the file system? How would some of the solutions affect data backups/restore on our side? Any comment on this is welcome. Thanks. Dave.
On Mon, 17 May 2004 14:08:40 +0200 (CEST) "David E. Meier" <dev@eth0.ch> wrote: | We would like to offer to some customers of ours some sort of network | backup/archive. They would put daily or weekly backups from their local | machine on our server using rsync and SSH. Therefore, they all have a | user account on our server. However, we must ensure that they would | absolutely not be able to access any data of each other at all. Just my 2 cents: I've found very useful some shells that permits just some subset of commands, for example shells/scponly, sysutils/bksh or sendmail's smrsh. Since you're using ssh you might also find useful the command= statement in .ssh/authorized_keys HTH Frankye
David E. Meier wrote:> Hello list. > > I would like to get your opinion on what is a safe multi-user environment. > The scenario: > > We would like to offer to some customers of ours some sort of network > backup/archive. They would put daily or weekly backups from their local > machine on our server using rsync and SSH. Therefore, they all have a user > account on our server. However, we must ensure that they would absolutely > not be able to access any data of each other at all. > > What is the "best and safest" way to do so? Regular UNIX permission > settings? File system ACL's? User jails? Restricting commands in their > path environment? Or would it even make sense to encrypt the file system? > How would some of the solutions affect data backups/restore on our side? > > Any comment on this is welcome. Thanks. Dave.Using a chroot or a jail is the way to go if possible. If you can't use that, then unix permissions or ACL's is the next bet. Restricting commands is the most fragile solution since in many cases it can be subverted. Encrypting the data is also useful if you have the horsepower. Richard Coleman richardcoleman@mindspring.com
On Mon, May 17, 2004 at 02:08:40PM +0200, David E. Meier wrote:> Hello list. > > I would like to get your opinion on what is a safe multi-user environment. > The scenario: > > We would like to offer to some customers of ours some sort of network > backup/archive. They would put daily or weekly backups from their local > machine on our server using rsync and SSH. Therefore, they all have a user > account on our server. However, we must ensure that they would absolutely > not be able to access any data of each other at all. > > What is the "best and safest" way to do so? Regular UNIX permission > settings? File system ACL's? User jails? Restricting commands in their > path environment? Or would it even make sense to encrypt the file system? > How would some of the solutions affect data backups/restore on our side?You generally would like to avoid giving people shell (ssh) access if you can avoid it. If you must give shell access, it is best to set up a jail. However, if you're just doing backup/file access - shell access isn't necessary. You can do ftps, (ports/ftp/bsdftpd-ssl), and easily use that to chroot users. You can do sftp (without ssh shell access), but that's trickier to set up. One popular solution these days is WebDAV. You use it along with apache, run it over https, and users can access their files with IE or other clients. dan
Bruce M Simpson wrote:> On Wed, Jun 09, 2004 at 07:52:23AM -0700, Crist J. Clark wrote: > >>To do scp-only, you either need (a) a hacked up sshd(8) daemon, (b) a >>jailed environment, or (c) a special shell for the user that only allows >>scp(1) to run. The funny thing is, I think (c) is probably the easiest >>to implement on a mass scale, but seems to be the option most seldom >>considered. > > > ports/shells/scponly > > BMSBruce, Indeed that is what i said as well :-) Cheers! -- Kind regards, Remko Lodder |remko@elvandar.org Reporter DSINet |remko@dsinet.org Projectleader Mostly-Harmless |remko@mostly-harmless.nl