Samba file server

[Karsten Wade]

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