-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2013 02:32 PM, Steve Lawrence wrote: > On 05/16/2013 10:10 AM, Daniel J Walsh wrote: On 05/16/2013 09:33 AM, Steve > Lawrence wrote: >>>> It has become clear that SETools has fallen behind userspace in terms >>>> of features and general maintenance. We would like to get it to the >>>> point where this is not the case, and to find a way to make sure it >>>> does not happen again. We think the solution to the maintenance issue >>>> is to make it more visible by merging the more useful parts of >>>> SETools into the userspace repo, while deprecating/removing the >>>> remaining pieces. >>>> > I think this would be a good idea. I have been adding sepolicy which > uses libapol and libqpol, to gather data from the installed policy. We > have several patches for setools that never made it upstream. We also are > heavy users of sesearch and seinfo, although would could replace these with > python tools using the seinfo and search python bindings. > > Over the summer we beginning to build a new gui based on the sesearch and > seinfo python bindings. along with a lot of the work we have done in > sepolicy. > > >> Is this code anywhere. We'd love to take a look at it. > >> Also, it sounds like reverting to an older verstion of libapol might >> break more things than we originally anticipated, so that might not be >> the best idea. Perhaps merging the current libapol into userspace and >> gradually working to reduce the complexity is the better route. > > Our first goal is to reveal all of the infomation that we currently have > in the SELinux Policy Man pages in an active presentation. The idea is to > allow an administrator to "browse" all of the policy that effects a > particular executable. For example the admin selects httpd and sees tabs > for all of the booleans, network ports, entry point paths, file types, > places apache can write, applications that apache can transition too. Not > just the types but also the actual values. > > # sepolicy network -d httpd_t httpd_t: tcp name_connect dns_port_t: 53 > http_port_t: 80,81,443,488,8008,8009,8443,9000 ocsp_port_t: 9080 > kerberos_port_t: 88,750,4444 pop_port_t: 106,109,110,143,220,993,995,1109 > smtp_port_t: 25,465,587 httpd_t: tcp name_bind ntop_port_t: 3000-3001 > http_cache_port_t: 8080,8118,8123,10001-10010 http_port_t: > 80,81,443,488,8008,8009,8443,9000 puppet_port_t: 8140 > jboss_messaging_port_t: 5445,5455 jboss_management_port_t: > 4712,4447,7600,9123,9990,9999,18001 httpd_t: udp name_bind > > # sepolicy transition -s httpd_t | head httpd_t @ httpd_suexec_exec_t --> > httpd_suexec_t httpd_t @ mailman_cgi_exec_t --> mailman_cgi_t httpd_t @ > abrt_retrace_worker_exec_t --> abrt_retrace_worker_t httpd_t @ > dirsrvadmin_unconfined_script_exec_t --> dirsrvadmin_unconfined_script_t > httpd_t @ nagios_services_plugin_exec_t --> nagios_services_plugin_t > httpd_t @ httpd_rotatelogs_exec_t --> httpd_rotatelogs_t httpd_t @ > pwauth_exec_t --> pwauth_t httpd_t @ abrt_helper_exec_t --> abrt_helper_t > httpd_t @ nagios_system_plugin_exec_t --> nagios_system_plugin_t httpd_t @ > sepgsql_trusted_proc_exec_t --> sepgsql_trusted_proc_t > > Then the next step would be to allow users, to customize the policy by > turning on booleans or changing network ports or adding file context. > > libapol and libqpol become critical to getting to this point. > > > In fedora and RHEL7 we are dropping support for a few of the executables > that we do not want to support. Also apps that have more traditional ways > of discovering the data. > > rpm -qla setools\* | grep bin /usr/bin/apol /usr/bin/seaudit > /usr/sbin/seaudit /usr/bin/sediff /usr/bin/seinfo /usr/bin/sesearch > >>>> However, we are well aware of the complexity of SETools, primarily >>>> libapol, and that upstreaming it without any changes would not solve >>>> the problems. So, we have done a little work behind the scenes to >>>> find a way to reduce the complexity of libapol. As a first stab at >>>> it, we started with an older version of libapol that is quite a bit >>>> less complex and began porting it forward for use with modern >>>> userspace, and seeing if it would make sense to eventually merge. But >>>> before we get too deep into this port, we wanted to start a >>>> discussion with the SELinux community to make sure we are headed in >>>> the right direction. So to start, does this seem like a good idea >>>> (both merging with userspace and porting older libapol)? Or should we >>>> take a completely different direction (e.g. the use of graphing >>>> databases as a replacement of apol has been mentioned in the past)? >>>> >>>> Another discussion we would like to have, which may affect the future >>>> of SETools/apol, is CIL. Is there still interest in CIL? And if so, >>>> have there been any thoughts on using and migrating to CIL? Is more >>>> work needed before this can happen? Has anyone put thought into >>>> higher level languages that could sit on top of CIL? If there is >>>> interest, this may affect the SETools changes, for example, syntactic >>>> policy analysis for CIL is likely very different than current >>>> policy. >>>> > As far as CIL is concerned, we love the idea, and would love to use it, but > we need to get it as a replacement for current policy with limited work. > > >> Good to hear. We'll keep that in mind. > >>>> Thanks, - Steve >>>> >>>> >>>> -- This message was distributed to subscribers of the selinux >>>> mailing list. If you no longer wish to subscribe, send mail to >>>> majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without >>>> quotes as the message. >>>> >>>> > >> > Most of it is upstream now policycoreutils/sepolicy/*.c in the upstream have the bindings. Basically is just taking sesearch and seinfo and making the data returned by those modules into python dictionaries. Then you can do stuff like python >>> import sepolicy sepolicy.get_all_domains() print >>> sepolicy.get_all_domains() ['sosreport_t', 'git_session_t', 'sshd_sandbox_t', 'cfengine_execd_t', 'bootloader_t', 'netutils_t', 'qmail_tcp_env_t', 'devicekit_power_t', 'zoneminder_t', 'httpd_collectd_script_t', 'sandbox_x_client_t', 'nova_api_t', 'sblim_reposd_t', 'dkim_milter_t', 'admin_crontab_t', 'consolekit_t', 'nova_compute_t', 'nova_console_t', 'pam_console_t', 'zarafa_gateway_t', 'policykit_grant_t', 'logrotate_t', 'openvswitch_t', 'update_modules_t', 'ssh_keysign_t', 'nova_network_t', 'qmail_rspawn_t', 'uml_switch_t', ... -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGfaZ4ACgkQrlYvE4MpobNWRQCeO8NLwMRBz+XCptQNf4ruUXff CqgAoK36YGZ5UGDNQ4dSPTgbBcKdLPWT =sfuv -----END PGP SIGNATURE----- -- This message was distributed to subscribers of the selinux mailing list. If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with the words "unsubscribe selinux" without quotes as the message.
