On Fri, 2005-01-07 at 15:52 -0500, Colin Walters wrote: > On Fri, 2005-01-07 at 13:29 -0700, Ivan Gyurdiev wrote: > > > That sounds like a hack. This isn't a home directory so why > > should I label it as such. It's a bunch of common files. > > Well, that's currently the type we use for data that users can modify. > It may be a bit weird given the name, but if from a security perspective > the files elsewhere are equivalent to the user's $HOME, then giving them > the same label makes sense. Heh, I knew I had the right answer but I wasn't sure why it was the only right answer. :) (me refers to grogginess mentioned earlier) > > Part of the problem in my mind is that I do not know what > > the SElinux types are, which ones I need to do what I want, > > and how to add new ones to perform this simple task. > > Right; this is something that should definitely be documented somewhere. > Both the purpose of existing types, as well as how to add new ones for > specific purposes. Documenting all the types sounds like a monumental task. It is also pretty dry reading (and writing). I could go on and on here, but IMHO this is not a manual documentation task. Similar is the idea of having a tutorial for every domain. Already that is an unwieldy idea for the targeted policy, and I *shudder* just thinking about it for the strict policy. Which brings us to a procedural and programmatic solution, the kind I much prefer. I'd like to hear developer ideas on this. Also, it would be nice to integrate this with the online documentation, meaning manual and info pages. Perhaps the pages could have an include that pulls a list of appropriate types from the policy. For example, the man page for sshd(8) would pull a formatted list of types (and tips) from /etc/selinux/policyname/docs/sshd.doc. The file sshd.doc is generated in the policy build (and supplied in binary policy and can be build from policy source), combining sshd.tips with an extraction of the types from the current policy. Similarly, sys.doc could be generated to give a view into all _sys_ types, sysadmr.doc could list all the things the sysadm_r role can do, and so forth. Essentially, all this stuff is there to find in the policy and using analysis tools such as apol. Be nice to make it easier for our friends the sysadmins than to make them into policy analysts. :) - Karsten -- Karsten Wade, RHCE, Sr. Tech Writer a lemon is just a melon in disguise http://people.redhat.com/kwade/ gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
