On Fri, 2004-11-05 at 09:37, John Logsdon wrote: > If a new version of program X comes out that is not FC2 specific and would > therefore not be linked into libselinux, won't that mean that we have to > re-implement it in FC2 - at least recompile. > > So if we have a closed-source program (ie we can't recompile) that > requires standard library, doesn't this raise an issue? I don't understand what you are asking. Programs only depend on libselinux if they include calls to its functions. Some programs in Fedora have been modified to make such calls, e.g. to get and set process and file security contexts, if SELinux is enabled in the kernel (otherwise,the SELinux processing is skipped, as you would want). There is some similarity to the modifications for ACLs and xattrs, which likewise introduced a dependency of e.g. coreutils on libacl and libattr. A new upstream version of coreutils won't yet include the SELinux changes, although that is the ultimate goal, so RedHat would presently have to merge the SELinux patch themselves when updating their package to the latest upstream version, but that is no different than the many other non-SELinux patches carried in the Fedora coreutils package (around 23 in the latest one that I have). You of course have the freedom to build your own coreutils without SELinux support compiled into it, although there is little point in doing so, as the support is runtime disabled when SELinux is disabled in your kernel. But that doesn't remove the linker dependency; you would need to change the SELinux patches to use dlopen() for that, as I said. > I would have thought that selinux libs should only be used by programs in > ..../selinux/bin - which should not be in the path of a non-SEL box. No, and this is not true either for ACLs or xattrs. ldd /bin/ls. > Shades of Big Brother that we have been trying to avoid in the OS movement > I thought. There are alternatives to SEL if you want security. And you are completely free to disable SELinux (and in FC2, that is the default) and use whatever you like. What is your problem? -- Stephen Smalley <sds@xxxxxxxxxxxxxx> National Security Agency
