# Trusted path execution and symlink permissions

## Melsion

Hi, I've been experimenting with the "Hardened" profile and kernel for the last few days and I've found a problem I don't really know how to fix.

After booting a kernel with "Trusted Path Execution" and "Partially restrict all non-root users" enabled, some scripts I used as a user wouldn't run complaining about permissions running sh. After reading the documentation I expected to be able to run any executable in /bin as long as it was only writable by root, so I checked file permissions in /bin and realized "sh" was a symlink to "bash". Running my scripts using bash worked perfectly, and the same applies to anything else, including python.

So, the problem are the symlink's permissions, wich are allways 777. I thought the actual permissions of the symlink where somehow inherited from the linked file, but for TPE they aren't.

Is there any way to circumvent this besides using direct paths for bash and python? I can live rewriting a few "sh" commands, but I'd have to rewrite every python call in my scripts when updating python versions...

----------

## Schnulli

HI

a Symlink is allways "root permissions"

Try adding your Users to the Group "root" and let us know if it works.....

(This was a shot in the blue)

Regards

----------

## Melsion

Hi Schnulli

thank you for your kind answer.

Your solution shouldn't work as the problem is that TPE blocks any executable that is not writable ONLY by root, that means anything with permissions above 755 can't be run, regardless of the group or the owner. Because symlinks always are 777 TPE will never allow them to run as long as it only looks for the symlink permissions and not the linked file permission's. It's designed as a way to keep any intruder from modifying any executable in the system. Also, adding a user to the root group would be a huge security hole, and defeat TPE's purpose, keep in mind I'm trying to harden my system's security.

Thank you anyway, I'll keep looking for a solution.

Regards.

----------

## jonathan183

You could create hardlinks to bash etc and change the permissions of the hardlinks ... other than that I think you are going to have to need to select one of the options https://wiki.gentoo.org/wiki/Hardened/Grsecurity_Trusted_Path_Execution which best suits your use case.

----------

## szatox

jonathan183, and for what filesystem would hard linking help?

E.g. ext2/3 stores permissions on the inode and all hardlinks are indistinguishable from each other (filename and hard link is exactly the same thing), so if you create several hard links and then start changing permissions, the permissions will always change for all hard links, because all those hard links point to the same file inode that stores only 1 set of permissions.

----------

## Melsion

All the options in the wiki (wich I followed to install TPE) lead to the same thing, not being able to exec files writable by group or others.

Hard links would be an option, but would there be a way to make portage install python or bash with hardlinks instead of symlinks? That's basically the problem, I can run python by calling it with "python2.7" or "python3.4", but not with "python" or "python3" as those are symlinks to the wrapper or the proper version.

I can (and already did) rewrite my scripts to point to the right file, but it'd like to avoid any problems when, for example, python-3.8 comes up on stable. Right now I'll have to rewrite my scripts before making the change... I can live with that, but I'd like to find the "less work" approach   :Laughing: 

----------

## jonathan183

 *szatox wrote:*   

> because all those hard links point to the same file inode that stores only 1 set of permissions.

  which is why hardlinks were suggested, the actual target has the desired permissions.

 *Melsion wrote:*   

> Hard links would be an option, but would there be a way to make portage install python or bash with hardlinks instead of symlinks?

  my approach would be to manually hard link after updates, you probably also need to keep a lookout for updates and revert to symlinks otherwise I suspect updates may fail.

To be honest, if I were going to that sort of time and effort then I would probably maintain a hard link from a non-standard location as well and leave the original symlinks in place. You would still need to delete and recreate hard links when the particular packages were updated.

----------

## mv

Somehow your original question makes no sense:

If you are a user not in a trusted group, typing "sh" should work without any problems, because sh and bash both reside in root-owned non-writable directories.

Of course, you cannot run your own scirpts (in the sense "$path_to/script", independent of script's shebang), because you cannot run in not root-owned directories at all. However, you can call "sh" and pass your script as an argument like "sh $path_to/script", of course.

----------

## Schnulli

let it then run as system process.... and set other permissions to the dir or file itself.....

Kinda SeLinux (UNIX Octa Rights) logic

regards

----------

