http://permalink.gmane.org/gmane.comp.security.selinux hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.comp.security.selinux/19341 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2013 02:32 PM, Steve Lawrence wrote: 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 ['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/ iEYEARECAAYFAlGfaZ4ACgkQrlYvE4MpobNWRQCeO8N</pre> Daniel J Walsh 2013-05-24T13:22:38 http://permalink.gmane.org/gmane.comp.security.selinux/19340 <pre> Nice! That would probably be a little difficult to deal with over email. I've given you commit access the CIL repo on oss.tresys.com. If you'd like, feel free to push your changes to a branch and I can give them a quick review before they go to master. </pre> Steve Lawrence 2013-05-23T20:24:49 http://permalink.gmane.org/gmane.comp.security.selinux/19338 <pre> A few changes were made. ;) b/Makefile | 38 b/include/cil/cil.h | 1 b/secilc.c | 51 - b/src/cil.c | 237 ++--- b/src/cil_binary.c | 1144 ++++++++++++++-------------- b/src/cil_binary.h | 4 b/src/cil_build_ast.c | 1717 +++++++++++++++++------------------------- b/src/cil_build_ast.h | 26 b/src/cil_copy_ast.c | 1265 +++++++----------------------- b/src/cil_copy_ast.h | 18 b/src/cil_fqn.c | 9 b/src/cil_internal.h | 136 +-- b/src/cil_list.c | 157 +-- b/src/cil_list.h | 25 b/src/cil_mem.c | 33 b/src/cil_mem.h | 4 b/src/cil_parser.c | 6 b/src/cil_policy.c | 610 ++++++++------ b/src/cil_post.c | 639 +++++++++++---- b/src/cil_resolve_ast.c | 889 ++++++++------------- b/src/cil_resolve_ast.h | 6 b/src/cil_symtab.c | 140 +-- b/src/cil_symtab.h | 9 b/src/cil_tree.c | 1959 +++++++++++++++++++++++++</pre> James Carter 2013-05-23T19:43:15 http://permalink.gmane.org/gmane.comp.security.selinux/19333 <pre> That's great to hear! Did this require any patches to CIL at all? I'd be happy to review any changes. Regarding the policy toolchain, I just tried to rebase to previous policy toolchain work/CIL integration and, not surprisingly, it ran into conflict issues on the very first patch. So it's probably not trivial, but I imagine it's not too difficult either. - Steve </pre> Steve Lawrence 2013-05-23T18:43:55 http://permalink.gmane.org/gmane.comp.security.selinux/19332 <pre> 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. Good to hear. We'll keep that in mind. </pre> Steve Lawrence 2013-05-23T18:32:12 http://permalink.gmane.org/gmane.comp.security.selinux/19331 <pre> Sorry it took so long to get back to you. The current version of libapol heavily relies on object oriented techniques, but is entirely written in C. For example, it uses iterators and a lot of function pointers to use something akin to inheritance. This makes it very awkward to program in and adds an unnecessary level of complexity. Going back to an older version would lose features and support for policy versions later than 20. The idea was that we would go back to a simpler point and rebuild or pull in the necessary features and newer policy version support. A because of the much simpler code base of an older version, adding back the features would hopefully not be too difficult. However, perhaps reducing the complexity isn't worth the effort. And maybe the dependence of tools in userspace would add more work. It sounds like maybe the best route might be to merge in libapol in it's current state. And as updates need to be made for Dan's and other tools that use libapol, we can gradually red</pre> Steve Lawrence 2013-05-23T18:28:03 http://permalink.gmane.org/gmane.comp.security.selinux/19330 <pre> BTW, the refpolicy interfaces for assigning these attributes can be found in policy/modules/kernel/mls.if file. </pre> Stephen Smalley 2013-05-23T16:34:39 http://permalink.gmane.org/gmane.comp.security.selinux/19329 <pre> You can generally override the MLS restrictions on a per-domain basis by assigning a specific type attribute to the domain. The specific attribute required can be gleaned from the policy/mls constraints, and refpolicy usually provides interfaces for doing so, but ultimately it just boils down to adding a typeattribute statement that assigns the requisite attribute to the domain and then the constraint will be satisfied. </pre> Stephen Smalley 2013-05-23T16:32:52 http://permalink.gmane.org/gmane.comp.security.selinux/19328 <pre>Hello everyone, I am having a hard time figuring out if what I want to do is possible knowing the way that the MLS policy is designed. Basically I am wondering if it is possible to write a module or do some sort of network labeling to allow a UDP stream to be sent from a higher level process on an SELinux machine to a lower classification machine (peer-labeled with netlabel). Here is what I am trying to do: s3 process -----&gt; s2 machine (netlabel) I am aware that this goes against the BLP model of no writes from high to low, but I just wanted to verify if it is possible to make and "exception" of sorts with SELinux. I have tried labeling outgoing packets with SECMARK to s2 but it is still denying the message based on the peer labeling. How do cross domain guards accomplish this since I think some are run on SELinux? Thanks, Blake </pre> Langland, Blake 2013-05-23T16:20:32 http://permalink.gmane.org/gmane.comp.security.selinux/19327 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2013 08:36 AM, Joshua Brindle wrote: Lets wait for Eric to chime in and get this resolved. We have a ton of new patches that I would also like to get upstream. :^) -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGeDwIACgkQrlYvE4MpobPd6ACgmU/OGZnyAh+Cvt38qB0SkBf5 W58AoJKGMgJZ0nHe5Xu49FeVsvT8EaPA =VC28 -----END PGP SIGNATURE----- </pre> Daniel J Walsh 2013-05-23T12:43:46 http://permalink.gmane.org/gmane.comp.security.selinux/19326 <pre>What were the relevant git hashes? On Thu, May 23, 2013 at 8:30 AM, Daniel J Walsh &lt;dwalsh-H+wXaHxf7aLQT0dZR+AlfA&lt; at &gt;public.gmane.org&gt; wrote: </pre> Joshua Brindle 2013-05-23T12:36:56 http://permalink.gmane.org/gmane.comp.security.selinux/19325 <pre>-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On 05/23/2013 08:10 AM, Stephen Smalley wrote: Yes this was a mistake. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.13 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlGeC/IACgkQrlYvE4MpobO9eQCg4nKtXkiv/rEIaCeDw8bOH0n/ 9GUAnji3pwYR6v9YeIzyR51Imj6RSWSM =xXXJ -----END PGP SIGNATURE----- </pre> Daniel J Walsh 2013-05-23T12:30:42 http://permalink.gmane.org/gmane.comp.security.selinux/19324 <pre> Maybe we should back out the relevant changes and cut another release? I agree that it is wrong for an upstream release to have Fedora-specific dependencies. </pre> Stephen Smalley 2013-05-23T12:10:39 http://permalink.gmane.org/gmane.comp.security.selinux/19323 <pre>Le Thu, 23 May 2013 07:30:18 +0200, Sven Vermeulen &lt;sven.vermeulen-kUv22x1vnyizQB+pC5nmwQ&lt; at &gt;public.gmane.org&gt; a écrit : Oh thanks, I messed this. Well I'm not a big fan of adding function in libraries that are not merged upstream. IIRC eparis told me on IRC that he has not happy with this new functions. Is this (or a reworked) function planned to be merged? Cheers Laurent Bigonville </pre> Laurent Bigonville 2013-05-23T07:57:47 http://permalink.gmane.org/gmane.comp.security.selinux/19322 <pre> Please see my answer to Joshua's announcement on the new userspace. You'll need to add in the function. There is also a dependency on yum Python bindings that you might need to remove, and depending on your directory structure you might need a /etc/selinux/sepolgen.conf (iirc) that defines where to find the refpolicy Makefile. Wkr, Sven Vermeulen </pre> Sven Vermeulen 2013-05-23T05:30:18 http://permalink.gmane.org/gmane.comp.security.selinux/19321 <pre>Hello, The last release of policycoreutils is using a function (selinux_current_policy_path()) that is only available in Fedora. I guess this shouldn't have made upstream. An idea how this could be sorted for other distributions? Cheers Laurent Bigonville </pre> Laurent Bigonville 2013-05-22T22:53:54 http://permalink.gmane.org/gmane.comp.security.selinux/19320 <pre>Ouch, i forgot to configure interface with 'semanage interface -a -t netif_t -r s1 eth0'. So, with that, i got expected result. Now, in audit a deny 'egress' avc appeared, and s4-&gt;s1 information flow stopped. Now everything is right, thanks a lot :) </pre> vlad halilov 2013-05-22T19:12:48 http://permalink.gmane.org/gmane.comp.security.selinux/19305 <pre> Yes, that information should still be correct. Yes, we do need better/proper documentation, there have been some efforts but they could use some additional information/help. This has been on my todo list for some time, but sadly other things keep stealing priority. Looking at the AVC denial messages is always the best way to understand the problem; there is a lot of good information in those denial messages. The problem is that a user_t:s1 process/socket can not receive netlabel_peer_t:s4 network traffic; since the problem is a constraint violation we know it is not a type enforcement problem, e.g. user_t not being able to receive netlabel_peer_t traffic, but rather a MLS problem, e.g. s1 not being able to receive s4 traffic. </pre> Paul Moore 2013-05-21T21:50:18 http://permalink.gmane.org/gmane.comp.security.selinux/19304 <pre> Ok, i note that. Btw, is this reference is actual http://marc.info/?l=selinux&amp;m=119991234501200&amp;w=2 ? Selinux extremaly need faq/best practice network guide. It's absence cause a basic error in network configuration like mine . Just audit2allow recommend to allow that, that that and that - so we just do it, don't think what and for what... Sure, it's a typo. I mean 192.168.1.196/32. I changed type to netif_t and that avc found in audit: type=AVC msg=audit(1369158708.220:821): avc: denied { write } for pid=2440 comm="nc" path="socket:[19743]" dev=sockfs ino=19743 scontext=user_u:user_r:user_t:s4 tcontext=user_u:user_r:user_t:s1 tclass=tcp_socket You right, i connected from unlabeled network from address with :s4 label, and used only static/fallback. So, now that look right. :s4 can not write to socket that connected to :s1 endpoint and avc present. Reverse channel s1-&gt;s4 is allowed. Yeah, that it: type=AVC msg=audit(1369160107.877:926): avc: denied { recv } for saddr=127.0.0.1 src=5000 daddr</pre> vlad halilov 2013-05-21T19:26:55 http://permalink.gmane.org/gmane.comp.security.selinux/19301 <pre>Yes, we have the same in Gentoo. Ack-by: Sven Vermeulen &lt;sven.vermeulen-kUv22x1vnyizQB+pC5nmwQ&lt; at &gt;public.gmane.org&gt; On May 20, 2013 6:31 PM, "Laurent Bigonville" &lt;bigon-8fiUuRrzOP0dnm+yROfE0A&lt; at &gt;public.gmane.org&gt; wrote: </pre> Sven Vermeulen 2013-05-21T14:31:02 http://permalink.gmane.org/gmane.comp.security.selinux/19288 <pre> A few comments on your configuration below ... Generally node_t is used for network nodes while netif_t is used for interfaces. I would recommend changing from "node_t:s1" to "netif_t:s1" and "node_t:s4" to "netif_t:s4". Also just for clarification, you do realize that 0.0.0.0/0 and 192.168.1.196/0 are the same, yes? In fact, you shouldn't even be able to configure the above you should get an "netlabelctl:error, File exists" error message (I do on my RHEL6 system). Perhaps a cut-and-paste error when writing your email? Good. Good. I assume that the external network/host is unlabeled and you are using the static/fallback labeling to label the incoming traffic? If so, could you first correct your static/fallback configuration (see above) and try again? Any AVC denials? You configured CIPSO to use only tag type #1 which is limited to categories c0.c240. If you want to use more than that you will need to look at the other tag types: enumerated (#2) or ranged (#5). Note that you can </pre> Paul Moore 2013-05-20T18:58:02 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.comp.security.selinux