New networking controls - FYI

[Stephen Smalley]

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