FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > Fedora SELinux Support

 
 
LinkBack Thread Tools
 
Old 02-06-2010, 11:19 PM
Mantaray
 
Default New networking controls - FYI

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.


-Ken-
--
selinux mailing list
selinux@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 
Old 02-16-2010, 12:45 PM
Stephen Smalley
 
Default New networking controls - FYI

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@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/selinux
 

Thread Tools




All times are GMT. The time now is 12:26 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org