We have such an system at my uni, too. It's a fscking pain in the ass. It uses some propietary cisco vpn system that requires a propietary cisco vpn client (a linux version, using a binary-only kernel module, is available)[1]. The software sucks ass. It can keep a vpn connection going for 20 minutes on a good day, but as soon as the wireless connection is less than perfect and starts dropping packets, the vpn connection will fail - *silently*. That's right, the only way to find out that your vpn tunnel is down is when suddenly no data gets through anymore. The client software will continue to cheerfully sit there and say it's still connected. Plus the (propietary cisco) hardware can apparently cope with no more than a handful of users concurrently. The IT guys refuse to replace the system despite everybody hating it, saying that there just are no alternative systems capable of the same workload. If they are right, then vpn won't solve your problem, unless the number of clients is _really_ small.
[1] A reverse engineered free client exists (vpnc). It doesn't implement all features, but it mostly works. That makes it more reliable than the propietary client, which mostly doesn't work, but it can't fix the flaws in the system.
Re:Seems to be a matter of reading 'man fstab' ...
on
A Closed Off System?
·
· Score: 1
The noexec flag will not prevent running binaries on other filesystems. You can run scripts even from a filesystem mounted noexec, you just have to call the interpreter explicitly (bash myscript.sh instead of./myscript.sh). Until a short while ago, you could use this even to run compiled binaries, using/lib/ld<something>.so — this was only fixed in recent kernels. And you don't need compiled binaries to 0wn a system. Bash is powerful enough by itself, Perl, Python, etc are even better, and widely deployed. In fact, for UNIXoid oerating systems, they are better, since you don't have to worry about binary compatibility any more.
Slashdot Mirror
We have such an system at my uni, too. It's a fscking pain in the ass.
It uses some propietary cisco vpn system that requires a propietary cisco vpn client (a linux version, using a binary-only kernel module, is available)[1]. The software sucks ass. It can keep a vpn connection going for 20 minutes on a good day, but as soon as the wireless connection is less than perfect and starts dropping packets, the vpn connection will fail - *silently*. That's right, the only way to find out that your vpn tunnel is down is when suddenly no data gets through anymore. The client software will continue to cheerfully sit there and say it's still connected. Plus the (propietary cisco) hardware can apparently cope with no more than a handful of users concurrently.
The IT guys refuse to replace the system despite everybody hating it, saying that there just are no alternative systems capable of the same workload. If they are right, then vpn won't solve your problem, unless the number of clients is _really_ small.
[1] A reverse engineered free client exists (vpnc). It doesn't implement all features, but it mostly works. That makes it more reliable than the propietary client, which mostly doesn't work, but it can't fix the flaws in the system.
The noexec flag will not prevent running binaries on other filesystems. You can run scripts even from a filesystem mounted noexec, you just have to call the interpreter explicitly (bash myscript.sh instead of ./myscript.sh). Until a short while ago, you could use this even to run compiled binaries, using /lib/ld<something>.so — this was only fixed in recent kernels. And you don't need compiled binaries to 0wn a system. Bash is powerful enough by itself, Perl, Python, etc are even better, and widely deployed. In fact, for UNIXoid oerating systems, they are better, since you don't have to worry about binary compatibility any more.