2

Does anyone know if it is possible to restrict execution of commands via dot slash notation for a directory?

The environment is bash on Linux.

For example, I have a directory /usr/local/app/bin. In /usr/local/app/bin is a command called foo. For some users I am creating an alias during login for foo that redirects foo elsewhere.

I don't want those users to be able to run foo directly by cd'ing to /usr/local/app/bin and running:

$ ./foo

These users need to be able to run other commands in /usr/local/app/bin but it doesn't matter if they are prevented from running these other commands via ./.

In the end, my goal is to restrict certain users from executing foo interactively when logging on interactively. For example (roughly), in .bashrc:

if [ -z "$PS1" ]; then
:
else
alias foo="echo access denied!"
fi

This works except users can run foo directly using ./ from /usr/local/app/bin The file needs to be executable, but only when the full path is used. I'm hoping someone knows a clever way to accomplish this

migrated from serverfault.com Jun 24 '15 at 3:00

This question came from our site for system and network administrators.

  • 2
    You can use file system permissions, for regular groups if you can manage those and alternatively use the more fine-grained ACL's – HBruijn Jun 23 '15 at 4:28
  • 1
    Your protection will be probably easily avoidable by copying the foo into a runnable directory and running it from there. – peterh Jun 23 '15 at 22:09
  • 3
    Could you possibly describe what are you trying to accomplish in the end? Or why do you want to do such a thing? (It seems there may be a better overall solution, as this sounds quite hacky and doesen't make much sense straight away.) – Fox Jun 23 '15 at 22:18
  • 1
    why does it matter that they use the full path? is "foo" not running correctly when using another relative path? (../bin/foo ? etc). what is the goal? (work around a bug in foo when invoked by something other that a full path? auditing where you want to know which of several "foo" was started? tell us the need, not the how) – Olivier Dulac Jun 24 '15 at 2:30
  • 1
    One way is to create a wrapper over foo - that checks the invocation directory, and if it finds everything in order, then invokes the hidden foo. – amisax Jun 24 '15 at 3:38
1

Everything is possible depending on how deep you want to go. On the assumption that you don't want to get into hacking your shell, kernel or get into selinux or AppArmour. No, you can't stop people executing foo (via ./foo or otherwise) without changing file system permissions or acls.

On Linux an executable is made executable based on file permissions, and posix acls. If they can execute it then they can execute it, only the executable itself can check if it should be run with the full path. If it's just a simple path problem you could wrap it in a shell and check the $0 argument, but for security this is really just obfuscation and anyone with a clue will get round in seconds.

Otherwise this is handled through acls and user and group executability. However, then you have to manage the user accounts, and file system acls and groups.

Usually files are owned by the admin account so for most user accounts they execute things through the group or other permission.

Remove the execute permission from "other".

chmod o-x /path/to/foo

Move the group membership of foo to a trusted group and make sure group execute permission is set.

chgrp trusted /path/to/foo
chmod g+x /path/to/foo

Now you have to put all the users who should be able to run foo into the trusted group.

for eachUser in a potentially a big long list of user accounts
do
    usermod --append --groups trusted $eachUser
done

And the management overhead of this is is why traditional Unix permissions suck.

For posix acls you can simply add the user to the file, but without the execute permission. Use getfacl to read the access control list.

for eachUser in a smaller list of restricted users
do
    setfacl -m user:$eachUser:000 /path/to/foo
done

Because the acl entry is there for the user account, it takes precedence over the default user/group/other file system permissions and the user has no permission on the file. Everyone else will be able to use the file as normally.

Better mathematically though is to put all the restricted accounts into a group, and add the group to the file with no permissions instead of individual users.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.