Tetsuo Handa
from-****@I-lov*****
Sat Nov 27 23:51:38 JST 2010
Jamie Nguyen wrote: > Tetsuo Handa wrote: > > Sorry, I didn't mean this line for copy&paste purpose. > > I wrote this line for showing "input"/"processing"/"output". > > When we implement this line, we will use a standalone program (maybe named > > /usr/sbin/ccs-learningd ). > > So this program would be run alongside ccs-editpolicy? If both can be > run simultaneously then this will basically have the same effect as > Learning Mode, but with the ability to control processing. Currently I'm expecting that /usr/sbin/ccs-learningd is started as a daemon when /sbin/ccs-init starts. > So in this case, would you agree that the workflow is something along > the lines of this?: > (1) Identify domain (automatic) > (2) Switch domain to profile=1 Permissive Mode > (3) Run /usr/sbin/ccs-learningd with desired proccessing options, with > output either to standard output or directly to domain_policy > (4) Adjust domain policy to allow desired access requests > (5) Switch domain to profile=2 Permissive Mode > (6) View logs > (7) Switch domain to profile=3 Enforcing Mode > Yes. But what do you want to do with the approach of "learning mode" by default? Jamie Nguyen wrote (before this thread has moved to this ML): > Hi, > > Tetsuo Handa wrote: > > What do you think of starting with "learning mode" for all domains? > > > > Currently, the documentation starts with "disabled mode" and let users > > change to other modes as needed. But if the documentation starts with > > "learning mode" and let users change to other modes, I can show pictures of > > the domain editor with the list populated relatively earlier steps. > > > > There is a tutorial http://tomoyo.sourceforge.jp/1.8/tutorial-1.html.en > > which is currently hidden from index.html because I haven't prepared rpm/deb > > repositories yet. This tutorial starts with "learning mode". Maybe starting > > with "learning mode" is more attractive and understandable for users. > > > > In that case, the documentation will look like > > > > (1) Install kernel and tools. > > (2) Run "/usr/lib/ccs/init_policy --use_profile=1". > > (3) Reboot with TOMOYO/AKARI kernel. > > (4) Login as root and run "/usr/sbin/ccs-editpolicy". > > (5) Explain about domain transition, profile, exception policy etc. > > (6) Play with TOMOYO/AKARI. > > (7) Tune policy (mainly converting pathnames using patterns) and > > save/load/edit policy (e.g. "/usr/sbin/ccs-editpolicy /etc/ccs/"). > > (8) Configure audit logs etc. > > (9) Use enforcing mode. > > (10) Explain software updates using interactive enforcing mode. > > I think this would be a very good idea. It makes sense to start in > learning mode, and then to disable as required. For the user, just > rebooting the system after running "/usr/lib/ccs/init_policy > --use_profile=1" will give lots of information on all domains that can > then be used to build a system-wide policy. > > There will always be users keen on just securing a small handful of > applications (e.g. web browser, server, PDF viewer etc). These users > would therefore not benefit much from starting with learning mode for > all domains, and a note could be made in the documentation to suggest > for such users to run "/usr/lib/ccs/init_policy" without the profile=1 > option and then to turn on learning mode explicitly for the required > domains. > If you prefer starting with "learning mode" for all domains, I think that we want to start /usr/sbin/ccs-learningd automatically. If you prefer starting with "disabled mode" for all domains, starting /usr/sbin/ccs-learningd manually is fine. But in that case, I think that use of /usr/lib/ccs/convert-audit-param and /usr/sbin/ccs-loadpolicy would be better. Regards.
TOMOYO
Fork