Il gio, 2004-03-11 alle 21:54, John Haxby ha scritto:
> Dario Lesca wrote:
>
> >Hi, someone know howto disable the execution of any command via ssh and
> >disable the scp/sftp service?
> >
> >OK; ssh user@host
> >NO: ssh user@host cat /etc/passwd
> >NO: scp user@host:/etc/passwd /tmp
> >NO: sftp user@host
> >
> >
> Apart from sftp (which as someone else said), the short answer is "no".
>
> You can't realistically control all the commands like this. SELinux
> might help, but I'm not sure and it's very hard to restrict a user's
> environment. Take the password file -- suppose you do prevent a user
> from just looking at it with cat, less, more, vi, view, emacs, xemacs,
> joe, jed, pico, dd, etc etc but still have ls work. "ls -l /home" will
> give you a fair slice of the password file in a different form. Type
> "echo ~<tab><tab>" in the shell and you'll also get a list of users.
> You could remove global read access from the password file, but you'll
> be surprised how many things break if you do. I once had the
> displeasure of maintaining a program that gave specified users access to
> a limited set of commands as root. It had a list of proscribed
> programs to stop you getting a shell to do what you like unaudited,
> things like sh, csh, ksh, bash, tcsh and so on. Of course, it didn't
> proscribe less, more, vi, view, emacs, xemacs, xterm, hpterm, dxterm
> etc. I simply removed the feature in the new version of the program,
> there's not much worse than having supposed security that is so easy to
> get around you'd hardly notice it was there.
>
> However, as someone else suggested. There is another way. A chrooted
> environment (like the one used for anonymous ftp) will lock a user into
> a limited environment. The only files that the user can get at are
> the ones in that chroot'd environment and there's no way to get out, you
> can't "cd .." from /. There are some really serious downsides to
> this. It's really quite difficult to set up and I'm not even sure that
> ssh has the right hooks to enforce it ("ssh host ls" runs /bin/ls
> directly, it doesn't go through a chrooting shell entry in /etc/passwd
> an I don't recall anything in the sshd config that forces a chroot.
> You could patch sshd to do it, but it's a measure of the difficulty of
> getting it to work effectively that it hasn't been done.
>
> That was a long no. Although I don't know much about it, I think
> you're better off looking at SELinux which almost certainly solves the
> security problems that you actually want to solve even if you don't know
> what they are -- yet.
For my problem, I have found this solution ... so, for the moment,
SElinux can wait ;-)
The target is assign to normal user the possibility to run a single
command (setup, or another), and only that one!
This is what I have make:
[root@igloo root]# cat /usr/local/bin/ssh.sh
#!/bin/bash
echo $0 $*
export DISPLAY=
exec /usr/bin/setup
[root@igloo root]# chmod 755 /usr/local/bin/ssh.sh
[root@igloo root]# useradd -s /usr/local/bin/ssh.sh sshuser
[root@igloo root]# passwd sshuser
Now Test all the metod
> >OK; ssh user@host
[root@igloo root]# ssh sshuser@localhost
sshuser@localhost's password:
/usr/local/bin/ssh.sh
You are attempting to run "setup" which requires administrative
privileges, but more information is needed in order to do so.
Password for root:<CTRL C>
Connection to localhost closed.
[root@igloo root]#
Ok, the command run propertly! ...
... via sudo then I can disable the password request ...
Now test other case ... I do not want that these work ....
> >NO: ssh user@host cat /etc/passwd
[root@igloo root]# ssh sshuser@localhost cat /etc/passwd
sshuser@localhost's password:
/usr/local/bin/ssh.sh -c cat /etc/passwd
[root@igloo root]#
NOT WORK! good!
> >NO: scp user@host:/etc/passwd .
[root@igloo root]# scp sshuser@localhost:/etc/passwd .
sshuser@localhost's password:
/usr/local/bin/ssh.sh -c scp -f /etc/passwd
[root@igloo root]# ls passwd
ls: passwd: No such file or directory
[root@igloo root]#
NOT WORK! good!
> >NO: sftp user@host
[root@igloo root]# sftp sshuser@localhost
Connecting to localhost...
sshuser@localhost's password:
Received message too long 796226418
[root@igloo root]#
NOT WORK!
This is all .... some suggest?
Many thank for your attention
--
Dario Lesca <d.lesca@xxxxxxxxxx>
