First, you can use auditing to tell what your users are up to.
Second, any developer worth hiring is going to get around that limitation in about 5 seconds.
Better take Perl away, too.
Third, as vbe said, if your developers can implement something on your production systems directly, you're sorely in need of
configuration management.
---------- Post updated at 01:35 PM ---------- Previous update was at 01:23 PM ----------
Quote:
Originally Posted by
Corona688
I agree with VBE. Restrict the data, not the tool. If you restrict permissions on the compiler too much, you may find yourself in an interesting catch-22 someday.
Either that, or be prepared to take away all assemblers, debuggers, linkers, and even hex editors. Along with just about every interpreted language such as Perl and PHP.
And if that doesn't break your system, there are almost certainly other ways to run arbitrary code.
Because what a user can do is limited only by the system calls that user can invoke, and the permissions that user has on the objects of those system calls.
A user's ability to read/write files, open TCP connections, or make any other system call is completely independent of the tool used to create any binary used to make those system calls.