On Tue, 2005-01-04 at 11:25 -0500, Stephen Smalley wrote: > "install" is akin to "rpm" in the > sense of installing a file, so it may make sense to initialize its > security context based on pathname at that time, because we have no real > runtime knowledge of its security properties and have presumably checked > its integrity in some manner prior to installation. But for normal > day-to-day file copying, the kernel (or some daemon) has no way of > knowing whether: Let's not have this devolve into the general file-copying problem, which consensus seems to be is insoluble. Here we're talking about a very specific case of software installation to well-known directories such as /usr/local/bin and /usr/local/lib. In this case we can presume the caller is highly trusted; anything with write access to those directories has to be. What we want to happen is for the shared libraries to be labeled correctly. > I'm not in favor of the daemon idea. Well, it's not beautiful. But we need some solution. Even if we got changes into Mozilla, Helixplayer, etc. to use a restorecon equivalent tomorrow, all of their existing tarballs would be broken, forever. Actually I just saw in CVS that Dan added the following permission: allow ldconfig_t lib_t:file r_file_perms; So essentially in the targeted policy only the targeted daemons will be unable to read shared libraries not installed by RPM. But for strict policy the above permission doesn't help; we'd need to grant it to everything which reads shlib_t. One other option besides the daemon is to have ldconfig itself do an automatic restorecon. This is less efficient since it will do so for every shared library, but given that ldconfig has always been the magic command you run to make shared libraries work, it does seem somewhat of a logical place to solve this particular problem. Long term we can push 'install' at these ISVs, and maybe around FC5 or FC6 if we have enough success, say that that's the only supported way to install files to the system.
