Dnia 2010-04-26, o godz. 12:28:45 Tetsuo Handa <from-****@I-lov*****> napisał(a): Thanks for the quick response. > > [Please CC, I'm not subscribed to the list] > > I'd like this one feature implemented to extend Tomoyo's reach to > > more desktop use cases. > > The feature would be simple: allow means to call a notification > > executable on any failed security hook if e.g. TOMOYO_ASK is > > set in the profile. Of course that application would have to be > > added to manager.conf if it needs to change the policy, but that's > > irrelevant. > > > > Some simple communication protocol would have to be defined (e.g. > > command line options). > > > This mechanism is already implemented regarding TOMOYO 1.x . Please > see "Step 2: Handling policy violation arising in during software > updates" in http://tomoyo.sourceforge.jp/1.7/enforcing.html.en . Yeah, ccs-queryd, must've missed it. Just needs a nice GUI (will write one). A sorely missing feature in 2.x. I'd love to see it there. Sounds like a simple /sys/kernel/security/tomoyo/query file for communication. (proc is not a place for those files) Although a deny_* match for every allow_* is necessary there to disable entries from showing up in the query daemon. (yes, some apps do dumb pointless thing) On an unrelated note, allow_file <match> could be useful too, a combo of allow_read/write, allow_create, allow_unlink and allow_truncate. (multi-alias?) > > Another semi-related feature would be to a way to disable logging > > for some matches. (ones expected to fail) This should reduce > > unnecessary clutter. > > Which one do you want to do? > > (1) Suppress audit log generation for per-operation (e.g. open > execute) basis. (2) Suppress audit log generation for per-pathname > (e.g. /bin/ /etc/ ) basis. I'd pick (2). > > Regarding TOMOYO 1.7 , (1) is implemented. > For example, you can generate audit log for execute operations > and can suppress audit log for open operations. This sounds nice, but it's not granular enough. > > In TOMOYO, all data is tokenized by ' ' and '\n'. You can filter > audit logs using "grep". Therefore, I don't have a plan to implement > (2). > Hmm, I was thinking like a new command here. no_log <match>. The idea is to possibly reduce load on syslog/auditd (think networked syslog) and not implement same matches in multiple places. Syslog might be missing matches TOMOYO has. Alternatively, deny_* matches might suppress logging too on some profile option, since they're expected already. Radoslaw
TOMOYO
Fork