• 1

Can you target a single executable with a local policy?

After following the steps to create a local policy for a new executable (from an rpm that I am developing) that complained about not being able to write a relocated shared library from a third party, the executable works. However, I worry about whether I haven't enabled all executables to relocate all shared libraries, because the contents of the .te file is simply:

module newexecutable 1.0;

require {
class file execmod;
type lib_t;
type unconfined_t;
role system_r;
};

allow unconfined_t lib_t:file execmod;

Is there a way of: 1) targetting the executable, or better, the directory containing the executables; 2) the particular shared libraries by the third party? I didn't want to chcon -t the third party shared libraries simply because they theoretically belong to a separate rpm installation that I shouldn't be modifying.

Peter K.

Re: Can you target a single executable with a local policy?

In this case the simpler/better solution is to change the context of the library to textrel_shlib_t.

# semanage fcontext -a -t textrel_shlib_t PATHTOLIB
# restorecon PATHTOLIB

The policy that you added would allow most non confined applications to load any library file with execmod. So I don't think this is a good idea or what you had in mind.

The third option would be to write a policy for the executable that uses the shared library and give it the priv to execmod lib_t, or create a special context for this library and only allow the policy to execmod this library.

You should report a bug to the owners of the PATHTOLIB, with a link to
http://people.redhat.com/~drepper/selinux-mem.html

Re: Can you target a single executable with a local policy?

(Anonymous)
Thanks for the quick response!

Yes, I accept that making PATHTOLIB textrel_shlib_t would solve the situation, but: 1) PATHTOLIB is supplied by a prominent commercial software company and I wouldn't like to tinker with their libraries for fear it would break their executables, which seem to operate fine without the need for textrel_shlib_t'ing their own libraries; 2) well, it's THEIR software and I don't want to change their installation anyway; and 3) if I disinstalled their software after doing the semanage fcontext, presumably the file context information relating to PATHTOLIB would be orphaned and not cleaned up.

So, I would like to stick to policies strictly related to my own executables and their installation and deinstallation scripts.

What would your third option look like, when applied only to my executable or directory of executables? How does a file or path name get entered into the .te file? Would I have to make my own MYEXECUTABLE_t type or category and thus have to supply more than just a simple .te file?

Peter K.

Org/IP/DRM/guide /) I recall the FBI warning saying something about not being able to reproduce if you were going to sell it.

  • 1
?

Log in