On Thu, 2006-11-30 at 14:32 -0500, Steve Friedman wrote: > On Thu, 30 Nov 2006, Stephen Smalley wrote: > > Yes, at present, it would be a matter of copying the new booleans.local > > into place and running semodule -B on the target machine. Going > > forward, we need utilities that can export/dump and import the data > > without requiring manual copying of the raw files. In the booleans > > case, that just means an option to getsebool to dump local booleans in a > > format easily consumed by setsebool (or some new option to setsebool); > > this requires finally migrating getsebool over to using libsemanage > > rather than directly reading the kernel state via selinuxfs (or at least > > supporting such an option as well). > > > > Great. One last question, if I may: are there any other ".local" files > besides booleans.local and file_contexts.local? This, plus Dan Walsh's > blog post (http://danwalsh.livejournal.com/8637.html, for the archives), > and I think that I am set. There can be, if local definitions are created via semanage by the admin, e.g. ports.local - local labeling of TCP or UDP ports interfaces.local - local labeling of network interfaces nodes.local - local labeling of hosts based on (netmask,address) users.local - local additions of SELinux users seusers - map Linux users to SELinux users Also, there can be local modules created by the admin, which could be named anything (*.pp) under the modules subdirectory; the names are just the module names. So local.pp would be common for people using audit2allow -M local as per the Fedora SELinux FAQ, but people may also be defining any number of more precisely named local modules to e.g. fix up issues they encounter with particular programs. Safest thing to do is to just rsync the entire policy tree and semodule -B it. -- Stephen Smalley National Security Agency -- fedora-selinux-list mailing list fedora-selinux-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-selinux-list