Thanks for your reply. Some of my friends already noticed me to type #seinfo or #sesearch both commands I didn't know... You say it's obvious that an administrator disabling dontaudit. Well, maybe... Yes, nobody does #semodule -DB unless he knows SELinux. Yes, he is diagnosing the machine. But, when it comes to Enforcing or Permissive, we have #getenforce. It's pretty good when I don't know whether or not Enforcing, I type that. I easily forget the present state and thanks to setroubleshootd, they tell me in red string when the system is in permissive. Other thing is that the contrivance you made, i.e. permissive domain. Yes, an administrator knows that he set some domain permissive and run the program to get audit log to make a policy. When I type #semodule -l, I get permissive_mydomain_t in alphabetical manner. It's quite all-right, but me forgettable easily forgets and makes mistakes, so in my tool, I tried to echo permissive_domain at the top of the #semodule -l. I admire that you are making many contrivances and I can catch up with, but my belief is that we should at least let an ordinary administrator know when he audit2allowed, he did in system permissive or some domain permissive or disabling audit. Well, last sentence is the idea that just hit me and never before. There are a lot of commands and I really appreciate them but above is are my beliefs. 2009/5/18 Daniel J Walsh <dwalsh@xxxxxxxxxx>: > On 05/16/2009 08:50 AM, Shintaro Fujiwara wrote: >> >> Thanks. >> >> So, I understand there are no commands checking present state of >> enabling or disabling dontaudit ? >> > Correct. Although you could use sesearch --dontaudit to see there are no > dontaudit rules in the policy. > >> And especially, disabling dontaudit survives next boot, for an >> ordinary administrator like me don't know whether or not disabling >> dontaudit. > > Yes semodule -DB rebuilds the /etc/selinux/targeted/policy/policy.VERSION > > file which will stay there until the next time you run semanage or semodule > (selinux-policy-targeted update for example) >> >> If I forget disabling dontaudit and don't know much about SELinux >> audit, if somebody tell me to do audit2allow and some buggy program >> running to manage shadow_t, I will foolishly may install a policy to >> manage shadow_t ? >> > Yes but you can always make this mistake. >> >> I think in that case, should be checked the present state of dontaudit >> disabled or not and giving advice to administrator to type command >> #semodue -B. >> > I don't agree, the only time some one should disable dontaudit rules would > be when trying to diagnose and SELinux problem, and the leaving SELinux > dontaudit rules disabled will be pretty evident in the number of AVC's that > will be coming to the machine. >> >> Well, I presently can manage at least making in certain confined area >> a file labeled shadow_t or whatever the dontaudit will be applied and >> check if the dontaudit is disabled or not. >> >> I think only ugly way but as an ordinary administrator, I can manage >> in that way. >> >> Thanks for your advices. >> >> >> >> 2009/5/16 Daniel J Walsh<dwalsh@xxxxxxxxxx>: >>> >>> On 05/15/2009 07:50 PM, Shintaro Fujiwara wrote: >>>> >>>> Hi, I typed, >>>> >>>> #semodule -DB >>>> >>>> How should I know if I succeeded disabled dontaudits ? >>>> >>>> Thanks. >>>> >>> If the command did not display any errors, it succeeded. Also you should >>> start to see a lot more avc messages. Start and stop a couple of >>> services. >>> >> >> >> > > -- http://intrajp.no-ip.com/ Home Page -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list
