Tetsuo Handa wrote:
> Maybe "Appendix A: Specification" shoule be "Appendix A: Policy Specification"
> and contain only policy specification. It became difficult to find the keyword
> in policy files.
>
> The specification/section-1.html.en ("A1: The userspace tools") could be moved
> to man-pages/index.html.en , and the specification/section-8.html.en
> ("A8: Authentication programs") could be moved to "Appendix J:".
> By moving A1 and A8 from specification/index.html.en ,
> "Appendix A: Specification" clearly becomes "Appendix A: Policy
> Specification".
Great idea. Now done.
> I noticed that
>
> The directory pathname must start and end with "/" and must not contain
> symbolic links, "//", "/./" or "/../".
>
> like tags/htdocs/1.8-tmp/section-7.html.en#file_pivot_root should be removed
> because a canonicalized pathname may no longer start with / .
Oops. I asked you about canonicalized pathname with purpose of adding
information about this, but I forgot. Will do this now.
> People think
>
> TOMOYO Linux provides the ability to generate policy automatically
>
> in 1.8-tmp/chapter-2.html.en#2.3 as important, but I don't think so. For me,
> it is no different from SELinux's audit2allow command or AppArmor's genprof
> command. The important thing for me is that users can configure TOMOYO with
> understanding. Configuring with understanding is important for
> troubleshooting.
> Thus, the statement should also refer configurability, customizability,
> managability, understandability etc.
OK agreed. I have changed to reflect.
> By the way, on the LSM ML, David Howells (the credentials maintainer) proposed
> a method for running multiple LSM modules in parallel. He tried to run SELinux
> and TOMOYO 2.3 in parallel and confirmed that SELinux and TOMOYO can run
> simultaneously on his test machine (because there is no interface conflict).
> During his attempt, he reviewed ccs-tools package and gave me some
> suggestions.
> I made some of changes where possible.
>
> I changed to use readymade manpages in order to remove help2man and gzip
> dependency.
>
> I removed example programs (e.g. falsh, candy, proxy) from usr_lib_ccs/
> directory (and moved to examples/ directory) in order to remove
> readline-devel dependency and keep /usr/lib/ccs/ clean. Now these example
> programs will not be compiled unless user explicitly compiles manually (as
> with programs listed in sftp/ssh-protection/ssh-recording/ssh-split pages).
So now, apart from the compiler tools which every program needs to
build anyway, the only real dependency is ncurses. That's pretty
awesome.
> He also suggested to use /usr/libexec/ccs/ rather than /usr/lib/ccs/ .
> Do you think we should move from /usr/lib/ccs/ to /usr/libexec/ccs/ ?
Well my first instinct is no. I checked the FHS:
http://www.pathname.com/fhs/pub/fhs-2.3.html
/usr/libexec is not listed there.
These example programs don't belong in /usr/lib at all I don't think.
Definition from FHS:
"/usr/lib includes object files, libraries, and internal binaries that
are not intended to be executed directly by users or shell scripts."
I am in favor of putting uncompiled source in /usr/share/ccs/examples
. I spot lots of *.c in /usr/share/gtk-2.0/demo as an example, so
other projects do this too. But if we stick with /usr/lib, then I
definitely prefer /usr/lib/ccs over /usr/libexec/ccs.
> Also, Casey Schaufler (the Smack maintainer) is considering proposing another
> method for running multiple LSM modules in parallel. Maybe something big
> change
> happens to LSM around 2.6.39 or 2.6.40.
I read archives and it's very interesting what Casey has had to say.
Glass LSM sounds very exciting. Now subscribed to LSM ML, which
fortunately does not have as high traffic as LKML :-)
Kind regards
_______________________________________________
tomoyo-dev-en mailing list
tomoyo-dev-en@lists.sourceforge.jp
http://lists.sourceforge.jp/mailman/listinfo/tomoyo-dev-en
