On Sun, 2008-01-06 at 14:23 -0500, Paul W. Frields wrote:
On Sun, 2008-01-06 at 23:43 +0900, Marc Wiriadisastra wrote:
> On Sun, 2008-01-06 at 20:29 +0900, Marc Wiriadisastra wrote:
> > Hey All,
> > It seems like someone was eager awhile ago
> > http://fedoraproject.org/wiki/Docs/Drafts/SELinux
has been put up
> > already. Should we use that link or change it to SELinuxGuide?
> > I'm going to start creating the pages over the next week or so. I would
> > like some input from everyone as to what to add.
> Just a quick email to say that I've added some stuff to the front page
> with the intention and other basic information. Can people have a read
> of it and comment so that we are all on the same page?
> If you think it requires further information or elaborating please post
> here so it can be discussed and we can come to a consensus on what the
> layout/content/methodology will be.
I think you may want to revisit the Approach. For example, I don't
think there are really any parallels between SELinux and MS Windows
functionality. And if you assume that the user has no familiarity with
UNIX/Linux concepts (which includes fundamentals), the guide needs to
explain how to log in, how to open a terminal, etc. You might want to
look at the existing documentation from Dan Walsh, et al., and try to
condense that into a set of objectives you want the user to be able to
achieve after reading each section of the documentation. This will give
you better coverage than just throwing a set of use case "bricks" at the
reader without seating them in a mortar of more fundamental practices.
A user who finishes reading this guide should be able to:
1. Understand how the Linux kernel, policy, and user tools work
together to implement SELinux in Fedora
2. Understand the differences and interactions between legacy UNIX
access controls and SELinux
3. Determine, set, and understand the operational mode of SELinux in a
4. Determine, set, and understand object and file labels
5. Understand how to perform an automatic relabeling of a file system
While I think the points above are great I think to tie it all together
the use cases would be of major importance.
My view would be explain basic functionality in 'x' chapter's including
concepts, tools and reasons. Have use case scenario's to 'paint a
picture' of how to extend one's basic knowledge to examples of what is
capable of being done with selinux. (Max seems to have a lot of those
and I think that talking to him will be integral)
Using this sort of objective-based criterion, you can figure out
skills you need to cover, and usually in what order, to make a guide
work, even if you have to condense information from a lot of different
sources. Once you have a general organization like this, you can have
it influence your outline for the doc. Hope this helps.
It does help a lot thanks for the feedback. Should we take the FAQ and
amalgamate it into this guide, it will use information from the FAQ
anyway. What is left over can be created as a FAQ of this guide?