On Tue, 2004-11-09 at 07:12, Thomas Vander Stichele wrote:
> The latter has a paragraph about where policy is stored, and mentions
> Makefiles and other stuff in /etc/selinux. None of this is present on
> my FC3 system, so I'm assuming here that Red Hat has changed some things
> from the default SELinux which obliviate this step, but I have way of
> finding out how. Am I missing something ? Maybe there's a package I
> need to install ?
FC3 places the policy under /etc/selinux/targeted (or strict, if using
that policy). By default, only the compiled policy
(selinux-policy-targeted) is installed, I think. You need to install
selinux-policy-targeted-sources for the policy sources. The policy
sources and Makefile are placed under /etc/selinux/targeted/src/policy.
> The former howto tells me I can run
> /sbin/fixfiles relabel /home/thomas/www
>
> but that command just gives me this:
> Usage: /sbin/fixfiles {-R rpmpackage[,rpmpackage...] [-l logfile ] [-o
> outputfile ] |check|restore|[-F] relabel}
>
> It would seem to me that what I issued was correct, both from the howto
> as well as the usage output. Clearly I'm missing something else here.
fixfiles doesn't take a list of directories, AFAIK, nor does the usage
message say that it does. It is just a script front-end by RedHat for
the setfiles program. setfiles was the original program, used to label
entire filesystems for an initial install of SELinux, although it can be
applied to a subtree.
> So I tried this:
> restorecon -v -R /home/thomas/www
>
> and that did something. How do these two tools differ ? Why does the
> first not work as advertised.
setfiles - The original upstream program. Relabels or checks entire
filesystems or at least a subtree starting from the specified
directories. Requires explicit specification of a file_contexts
configuration and of the list of directories to traverse.
fixfiles - script front-end by RedHat for setfiles. Doesn't require (or
even permit) specification of a file_contexts configuration or a list of
directories to traverse; has some additional features like being able to
selectively relabel all files in a given package.
restorecon - variant of setfiles program by RedHat. Doesn't require or
permit specification of a file_contexts configuration; does require
specification of paths to relabel; only traverses directories
recursively if -R is specified. This is more like a chown/chmod-style
program, except you don't have to specify the context itself, as that is
obtained from the file_contexts configuration based on the pathname.
Over time, restorecon has been getting more and more like setfiles (e.g.
via -R option); it just presents a different default interface to the
user. Should likely be merged with setfiles in some manner.
chcon - chown/chmod equivalent for security contexts. You specify the
context and the individual files, can also recurse via -R.
> Using ls -alz /home/thomas I seem to get the impression this security
> context has been adopted. Still, apache refuses to see the directory.
>From the initial denial, it looked like apache couldn't even search the
top-level home directory ("thomas") because it lacked the proper
security context (should have user_home_dir_t, not default_t).
restorecon -R /home/thomas.
> So I read some more of the howto. There's a binary called audit2allow
> that could help me generate rules. So I run it, restart apache a few
> times, but the binary doesn't print anything, not even with -v. Maybe
> I'm using it wrong, but there's no way of finding out if I am.
audit2allow -d (to read audit from dmesg output) or audit2allow -i
/var/log/messages (to read from the messages file). Otherwise, it
defaults to acting as a filter, reading from stdin. Possibly not the
best choice of interface.
> Maybe it would be a good idea to write a simple "getting started" guide
> explaining how to do two or three common tasks (I'd say "serving web
> pages from a nonstandard directory" would be one of them), making sure
> that EVERY STEP works. Right now the howto contains things that do not
> work as advertised, and links to docs that reference stuff that is not
> present, without a mention close by where to get it.
I think Colin has/is working on such a guide. I agree that the existing
documentation is inadequate, and that part of the problem is that there
is too much reliance on documentation that predates the Fedora SELinux
integration and doesn't reflect changes made for it. Even FC2->FC3
introduced a lot of changes, so some documentation that was updated for
FC2 is now out of date.
> - A lot of developers I know, including a bunch at Red Hat, *turn off
> SELINUX entirely*. IMO, something that gets pushed at heavily as this
> should be dogfooded by the development team at Red Hat completely, so
> they encounter firsthand what it means and how to fix basic issues.
> Knowledge spreads through increasingly growing circles starting from the
> center. If all RH developers, who have "easy" access to the SELINUX
> people at Red Hat, were to use it, they'd have basic knowledge about it.
> When the next circle of developers - outside of redhat, but having links
> to inside - gets hit, they do the same. And so on.
>
> It looks to me like the first circle is already completely broken, hence
> halting the dissemination of information and increasing the annoyance
> level outside of Red Hat. It won't be long before sysadmins and users
> ignore the default and turn it off entirely.
Fair point, no argument here.
> - The documentation is not easy to find, out of date, and doesn't match
> the system. IMO, if FC3 gets released, the howto for something as basic
> as SELINUX should be uptodate and easy to find.
Yes, and either there shouldn't be so much reliance on pre-existing
documentation that predates Fedora SELinux integration or Fedora project
should be submitting patches to update that pre-existing documentation.
> I just want to get a good picture of where SELINUX is at and how to
> solve issues, so that I can try to fix stuff myself, and explain to
> other people. Otherwise I'll just have to turn off SELINUX myself, and
> recommend the same to others when questions are asked about it.
>
> Feel free to comment, both on the particular issue at hand as well as
> the general issue of entry barriers to selinux.
Thanks for the feedback, and sorry for your troubles.
--
Stephen Smalley <sds@xxxxxxxxxxxxxx>
National Security Agency
