Linux - Security This forum is for all security related questions.
Questions, tips, system compromises, firewalls, etc. are all included here. |
Notices |
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
Are you new to LinuxQuestions.org? Visit the following links:
Site Howto |
Site FAQ |
Sitemap |
Register Now
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
|
|
04-17-2007, 01:37 PM
|
#1
|
LQ Newbie
Registered: Apr 2007
Posts: 2
Rep:
|
securing an executable some users may USE it, but not COPY it.
I hope someone out there can give me some tips on my current conundrum.
We're getting a new piece of analysis software here. A government agency is allowing our foreign national employees to use the software as long as it's installed on a server and:
"
1) the source code cannot be read or copied
2) the executable can be executed, but cannot be copied.
"
I know how to prevent a user from reading and copying the source code, but how do I prevent a user from copying an executable? This seems tough to do. We can argue that it will be useless without the linked libraries, but it feasible that someone could re-install it on a similarly configured system.
I'm not exactly sure what the nature of this new software is, but I'm guessing that it's going to be sent to us as C or FORTRAN source code. We are waiting for more information.
I'm using RHEL4. I consider myself to be moderately competent, but not a expert with Linux. Thanks for any advice/ideas.
|
|
|
04-17-2007, 02:00 PM
|
#2
|
LQ Guru
Registered: May 2005
Location: Atlanta Georgia USA
Distribution: Redhat (RHEL), CentOS, Fedora, CoreOS, Debian, FreeBSD, HP-UX, Solaris, SCO
Posts: 7,831
|
Of course there is basic permissions (man chmod): read, write, execute. Setting only execute and not read might work. Often directory permissions might allow them to do read/copy that the file permissions don't allow for.
You could investigate Access Control Lists (ACLs) that are more granular control for files than standard permissions (man setfacl).
However, if it were me in your shoes I'd probably:
A) Insure no one there had root access.
B) Setup sudo to do the execution. That way the user
-Has to input a password when he uses sudo
-Only executes sudo which in turn executes the program
Since sudo by default runs as root you could give permissions ONLY to root for read and execute. No one could read it then except root. Since sudo deals with execute rather than read they would not be able to read it even using the sudo command.
Also it doesn't HAVE to run as root. You could create an admin user and have them do a sudo command that su's to that admin user and executes it as that admin user. Here again you'd want to make sure no one had direct access to login as the admin user and that permissions were restricted to read and execute only for the admin user.
|
|
|
04-17-2007, 02:49 PM
|
#3
|
Senior Member
Registered: Nov 2003
Location: Knoxville, TN
Distribution: Kubuntu 9.04
Posts: 1,168
Rep:
|
Could you use something like X forwarding over ssh? That would keep everything executing on the server-side. If it's going to run client-side I really don't see how you can avoid copying it over the network.
Last edited by Crito; 04-17-2007 at 02:50 PM.
|
|
|
04-17-2007, 02:57 PM
|
#4
|
LQ Guru
Registered: Nov 2004
Location: San Jose, CA
Distribution: Debian, Arch
Posts: 8,507
Rep:
|
You can set just the execute permissions on a program for a user. The file then cannot be read/copied/etc, but can be run.
|
|
|
04-17-2007, 03:30 PM
|
#5
|
LQ Newbie
Registered: Apr 2007
Posts: 2
Original Poster
Rep:
|
setting only the execute bit works
thanks for the rapid suggestions!
I experimented with these. At first, setting just the execute bit wasn't working... but, i was (stupidly) testing it with a simple Perl script... It took me a while to figure out that the read bit must be set to in order for /usr/bin/perl to interpret the code.
I tested it on a compiled C++ program and it works perfectly. When another user tried to copy the executable, it just complains:
cp: cannot open `/home/wsimmons/test/Hello' for reading: Permission denied
Thanks for the help.
|
|
|
All times are GMT -5. The time now is 09:11 AM.
|
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
|
Latest Threads
LQ News
|
|