> Off the cuff: all student dirs have a group owner of "professors" with
> rwx perm, and students are not in that group.
> Professors are in group "professors" and the group owner of their dirs
> is "professors" but the perms for group are blank (or make the group
> owner "admins" or something).
> Make use of sgid and umask so everything stays proper. Not sure about
> chrooting. Is that really needed?
> I think that should work if you just want to stop casual
> interference/reading. If you want to presume that students and/or
> professors may mount sophisticated, persistent attacks, you need to
> setup much more serious security, probably including ACLs,
> Capabilities, SELinux, restricted shells, etc.
> I am not a security expert at all, salt to taste.
>
> Cheers,
> Kelly Clowers
>
Hi Kelly, hi guys,
Thanks for the explanation. I never used SUID, GUID and UMASK, so I
did some research about it here [5]. I see that this could probably
work. It's weird though to have a student issue the command
$ls -l
and see his files owned by him, and group professor, him being a student.
-rwx------ 3 sam professor 4kB Mar 29 15:59 studsamfile.txt
But I think I can do the same by letting students in group student,
and adding all professors to that group also, can't I?
Lets say this examples here:
/etc/group
student:...:sam,simon,sony
professor:...:paul,peter,patrick
admin:...:alf,art,abbie
I wonder, can't a student simple give the command chown and make a
mess with it all?
Now, maybe this group permission is a good way to deal with who can
see what, but the main point of the thread [1] is CHROOTing the users
inside /home. Yes, Kelly, I do believe they can cause
(non-sophisticated) problems, because I saw some history commands
(like this one I can't explain: $explode professor's computer,
hopefully I did not had 'explode' package installed, and all the
student got was a 'command not found'). Also, this server has a very
fast link with a governmental institution that must be preserved by
outsider's attacks (that can be a little more sophisticated).
I'll not install ACL or SELinux, but if by restricted shell you mean
chroot a system, then yes. Lets get back on track.
>From [2][3] I got that to keep ftp on /home is easy. But the site is
for debian lenny.
I just need a working sftp to change to
$vi /etc/ssh/sshd_config
Match Group users
ChrootDirectory /home
AllowTCPForwarding no
X11Forwarding no
ForceCommand /usr/lib/openssh/sftp-server
Match
Restart OpenSSH:
$/etc/init.d/ssh restart
And quote: "If you chroot multiple users to the same directory, but
don't want the users to browse the home directories of the other
users, you can change the permissions of each home directory as
follows:"
$chmod 700 /home/falko
Now this chmod may conflict with the previous solution.
Still [3] tells me there is a script that helps locking a user to the
home directory. Is this the procedure to follow in debian squeeze?
$cd /usr/local/sbin
$wget
http://www.fuschlberger.net/programs/ssh-scp-sftp-chroot-jail/make_chroot_jail.sh
$chmod 700 /usr/local/sbin/make_chroot_jail.sh
In [4] I found that I need to manually copy a lot of programs to the
new root. Do I really need that? Is there an easy way to prevent
something like $cd .. from a user in his dir?
Thanks guys,
Beco
[1] Maybe I did asked for a solution to a problem that should be
addressed in both ways: group perms and chroot. If that is the case, a
moderator might want to split the thread to something like: group
permissions (was chroot ssh and ftp)
[2] http://netport.org/?p=379
[3] http://www.howtoforge.com/chrooted-ssh-sftp-tutorial-debian-lenny
[4] http://www.cyberciti.biz/tips/howto-linux-unix-rssh-chroot-jail-setup.html
[5] http://forums.eukhost.com/f30/more-file-permissions-suid-sgid-umask-882/
--
Dr. Beco
A.I. research, Cognitive Scientist and Philosopher
Linux Counter #201942
--
To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/CALuYw2z430=170Z5R++N21G+iCb=t_embqupv_jg031mwmw...@mail.gmail.com
