On Sat, 2010-02-06 at 17:19 -0700, Mantaray wrote:
> List members,
>
> I have recently upgraded to the 2.6.30 kernel, and I am now using the
> new networking controls. I have noticed difficulties that seem to me to
> be similar difficulties in some other recent posts, so I wanted to make
> a brief post regarding the matter.
> I tested the packet rules by creating packet labels for the local ipv6
> (::1), my printer, my router, and general internet addresses. I did not
> give my son's user permission to access the printer. When his user
> attempted to access the printer, the application being used would hang
> and need to be shut down. Allowing local ipv6 packets to be
> sent/received by his user prevented the application from hanging, but
> also allowed his user to access the printer - with no packet access
> allowed to the printer. When this did not restrict his access, I added
> a constraint in the constraints file:
>
> constrain packet { recv send }
> (
> r1 != his_user_name_r
> or t2 == allow_packet
> );
>
> This constraint prevented access to the local ipv6 packets until I added
> the attribute type to those packets, but access to the printer was not
> affected.
>
> For now my packet rules for Internet access appear to work and I am
> limiting printer access through the print service directly. I do not
> presently have time to troubleshoot the matter, so for now this will do
> as a solution; but I am curious why the packet controls (especially
> combined with the constraint) are not preventing printer access.
>
> I know that there are other controls that are intended to restrict
> network access, and I have not yet had the time to explore using these
> controls. I am hopeful that by combining these controls with the
> SECMARK controls, I will have better control of network traffic; however
> one recent post (by Jason on February 2) seems to indicate that there
> may still be some difficulty getting these other controls to properly
> restrict network traffic as well: "I found that my test app (with the
> allow rule below), could still read and display packet data coming in on
> any interface even with all interfaces assigned a unique peer_t...."
>
> I really appreciate the efforts of everyone involved in the development
> of SELinux, and I hope my comments will help the developers to make the
> new controls as effective and easy to implement as the previous controls
> were.
Is his domain allowed to communicate via the Unix/local socket
named /var/run/cups/cups.sock? That would show up as permission to
write to cupsd_var_run_t:sock_file and to connectto
cupsd_t:unix_stream_socket. The default /etc/cups/cupsd.conf
says to listen on both localhost:631 and /var/run/cups/cups.sock.
--
Stephen Smalley
National Security Agency
--
selinux mailing list
selinux@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/selinux
