Hello,
I am curious that is there a way I can restrict a user or a set of users to execute the C/C++ compiler, basically what I want is to lock it down to a particular user and none of the other users should be able to compile any code.
Thanks in advance.
Maybe if you explained a bit more why/what you are up to can we see if there are some ways of doing...
Thanks for replying vbe.
We don't want all the application team to compile codes and implement it even by mistake. So we want to lock it down to a single user, so if they have to compile a code, they have to either sudo or su to that user and do their work, such that we can keep a track of who's doing what.
Can you do this with the file permissions of the compilation command? If it's /usr/bin/cc then a chmod 500 /usr/bin/cc would tie it down to owner access only. You could expand that a little to have chmod 550 /usr/bin/cc so that the owner & group listed on ls -l /usr/bin/cc would be able to run it.
You could change the group and have in only the account(s) that you want to be able to use it.
I hope that this helps,
Robin
Compiling code doesnt give you the right to implement it you know...
When you compile the generated executable is by default in the current directory or HOME etc.. to compile so it is implemented means you are root...
In other words compiling and implementing are 2 different things you must allow application team to compile, but in any case that team has the right to implement, what they have compiled just pass tests first in dev etc... then they should issue and RFC for the quality team to examin and decide...
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.
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 ----------
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.
Thanks for the response guys!
This gonna be in production and this will hit audit, our concern was what is the best way to avoid having a c/c++ compiler in production?
That depends what you need to do in production... If you're asking how to deploy software without compiling it, you could prepare installable packages of executables from your software on the development and deploy them to production instead of compiling them on production.
Yes, our intention is to do that (have them compile on DEV and then deploy on PROD), but application team is emphasizing on having a compiler on prod system saying they are in to critical phase and want to lock down the compiler to a particular user instead of removing it from server.
I'd be tempted to just make them compile on dev, rather than polluting production with extra things from dev.
You could compromise by giving them what I suspect they really need -- the ability to modify production with last-minute changes. NFS-map a few folders from production into dev so it's less of a round-trip to make fixes.
Installing a compiler in the first place adds tons of things which might not clean up well. Customizing it could make that worse.
Very true, that is our fear, what if someone goes and poke his nose around code at the last moment.
And again it seems like there is no way I can limit the c/c++ compiler access to a particular user or lock it down.
Having a compiler does not create that risk. If user1 and user2 can both run cp command, does that mean user2 can copy user1's files? Not necessarily.
So the issue isn't the compiler, it's about having the code on the production server at all.
I see no reason the code has to be on the production server. I don't see why a compiler needs to be either. Get them to give you a good reason they can't just NFS-mount a folder to copy executables for convenient testing.
Agreed.
If the developers claim to NEED a compiler on the production system is true, they're not testing their code enough.
Not only that, compiling code on a production server means the binaries on that server have never been tested. Running "./configure; make; make install" is not how to repeatably deploy reliable, tested software.
Thanks a lot guys.