9:47 a.m.
[Posting here for lack of a better place...]
Attached is a patch against the current selinux.sourceforge.net repo,
along with an archive of additional files that contain the policies
for non-CUPS software.
The patch fixes incompatibilities with the current CUPS 1.2 software
and removes the non-CUPS software rules from the CUPS policy files.
The CUPS 1.2 changes involve adding domain socket support and adding
the new files and directories introduced in 1.2...
I removed the non-CUPS rules because the mix of software makes
debugging and validating the CUPS policies that much harder, and it
makes sense to maintain the policies for separate projects
separately...
Anyways, comments welcome!
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
1:21 a.m.
On Saturday 12 November 2005 02:47, Michael Sweet <mike(a)easysw.com> wrote:
I removed the non-CUPS rules because the mix of software makes
debugging and validating the CUPS policies that much harder, and it
makes sense to maintain the policies for separate projects
separately...
Firstly, please test your patches first. There is no name_connect access in
the unix_stream_socket class or a seteuid capability.
Please don't remove comments such as "this is not ideal, and allowing setattr
access to cupsd_etc_t is wrong". That's a design flaw in cupsd, eventually
we want to fix it. Removing the comment decreases the chance of such a
design flaw ever being corrected.
The hplip and ptal policies are OK in the same file as cups. They are
printer-specific programs. Having separate lpd and cups files is more of a
problem. As we seem to be moving away from the traditional lpd we will
probably change things in this regard.
When there is policy involving access between initrc_t and the domains/types
defined in a daemon policy file then this belongs in the policy file for the
daemon. Important files such as initrc.te should not have sections for all
the many daemons that need to interact with them.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
7:18 a.m.
Russell Coker wrote:
On Saturday 12 November 2005 02:47, Michael Sweet
<mike(a)easysw.com> wrote:
> I removed the non-CUPS rules because the mix of software makes
> debugging and validating the CUPS policies that much harder, and it
> makes sense to maintain the policies for separate projects
> separately...
Firstly, please test your patches first. There is no name_connect access in
the unix_stream_socket class or a seteuid capability.
Sorry, I had tested the file context changes but not the rest (still
getting my feet wet). I mainly wanted to a) alert folks to a problem
with the current policy and b) get feedback.
Please don't remove comments such as "this is not ideal, and
allowing setattr
access to cupsd_etc_t is wrong". That's a design flaw in cupsd, eventually
we want to fix it. Removing the comment decreases the chance of such a
design flaw ever being corrected.
Well, given that the comment does not describe the "design flaw" in
enough detail to be useful, and that no one has posted this "design
flaw" to any of the CUPS forums or the STR page on the CUPS site, it
seemed like I was removing a comment that was confusing and
uninformative.
What is the design flaw?
The hplip and ptal policies are OK in the same file as cups. They
are
printer-specific programs. Having separate lpd and cups files is more of a
problem. As we seem to be moving away from the traditional lpd we will
probably change things in this regard.
When there is policy involving access between initrc_t and the domains/types
defined in a daemon policy file then this belongs in the policy file for the
daemon. Important files such as initrc.te should not have sections for all
the many daemons that need to interact with them.
Fair enough. Can we at least segment the rules in each of the files
so that it is clear which rules apply to which sub-programs?
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
7:46 a.m.
On Sunday 13 November 2005 00:18, Michael Sweet <mike(a)easysw.com> wrote:
> Please don't remove comments such as "this is not
ideal, and allowing
> setattr access to cupsd_etc_t is wrong". That's a design flaw in cupsd,
> eventually we want to fix it. Removing the comment decreases the chance
> of such a design flaw ever being corrected.
Well, given that the comment does not describe the "design flaw" in
enough detail to be useful, and that no one has posted this "design
flaw" to any of the CUPS forums or the STR page on the CUPS site, it
seemed like I was removing a comment that was confusing and
uninformative.
What is the design flaw?
The fact that cups requires write access to it's config directory and all
config files.
> The hplip and ptal policies are OK in the same file as cups.
They are
> printer-specific programs. Having separate lpd and cups files is more of
> a problem. As we seem to be moving away from the traditional lpd we will
> probably change things in this regard.
>
> When there is policy involving access between initrc_t and the
> domains/types defined in a daemon policy file then this belongs in the
> policy file for the daemon. Important files such as initrc.te should not
> have sections for all the many daemons that need to interact with them.
Fair enough. Can we at least segment the rules in each of the files
so that it is clear which rules apply to which sub-programs?
Sure.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
8:44 a.m.
Russell Coker wrote:
On Sunday 13 November 2005 00:18, Michael Sweet
<mike(a)easysw.com> wrote:
>> Please don't remove comments such as "this is not ideal, and allowing
>> setattr access to cupsd_etc_t is wrong". That's a design flaw in
cupsd,
>> eventually we want to fix it. Removing the comment decreases the chance
>> of such a design flaw ever being corrected.
> Well, given that the comment does not describe the "design flaw" in
> enough detail to be useful, and that no one has posted this "design
> flaw" to any of the CUPS forums or the STR page on the CUPS site, it
> seemed like I was removing a comment that was confusing and
> uninformative.
>
> What is the design flaw?
The fact that cups requires write access to it's config directory and all
config files.
I know some people would prefer to hand-edit all files and place printer
state data in 5 different places, however no one has proposed an
alternate location for these files that makes sense WRT to the FHS.
We are absolutely committed to making CUPS easy-to-use, which means
allowing programs (in particular cupsd, which can provide finer-grained
authorization/access control to the configuration data than selinux) to
edit those files. CUPS also updates the printers.conf, classes.conf,
and subscriptions.conf files based on (persistent) state changes.
Anyways, I will update the comment to reflect this discussion.
........
On a related note, you have comments on a few other rules I'm not
clear on:
# temporary solution, we need something better
allow cupsd_t serial_device:chr_file rw_file_perms;
I'm guessing this refers to allowing write access to all serial ports?
Any thoughts/wishes on this end? We've looked at a variety of schemes
to identifying serial printer ports - providing separate device links
would seem to be the simplest solution - but there would need to be
some standardization (i.e. Linux distributors need to use it) for it to
be effective.
# for /var/lib/defoma
allow cupsd_t var_lib_t:dir search;
r_dir_file(cupsd_t, readable_t)
This appears to provide read/search access to files in /var/lib, but
I'm confused by the "defoma" bit?
# lots of errors generated requiring the following
allow cupsd_t self:netlink_audit_socket {
create_netlink_socket_perms nlmsg_relay };
allow cupsd_t self:netlink_route_socket { r_netlink_socket_perms };
What errors are generated? What programs are involved? Why are we
allowing rather than fixing?
Thanks again for your feedback - I hope my next patch will be both
less invasive and more accurate... :)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Publishing Software http://www.easysw.com
9:30 a.m.
On Fri, 2005-11-11 at 10:47 -0500, Michael Sweet wrote:
[Posting here for lack of a better place...]
Just FYI, selinux(a)tycho.nsa.gov is the upstream SELinux mailing list.
List info is at http://www.nsa.gov/selinux/info/list.cfm.
fedora-selinux-list is fine too, particularly for Fedora-specific items,
but since your patch was against the sourceforge CVS, it was more likely
suited to the main list.
Various SELinux information resources are listed at
http://selinux.sf.net/resources.php3.
Attached is a patch against the current selinux.sourceforge.net
repo,
along with an archive of additional files that contain the policies
for non-CUPS software.
Thanks for working on this, as it would definitely be a win to have the
upstream maintainers of the various software packages helping to
maintain the corresponding policy.
One thing to be aware of is that the current upstream example policy is
in process of being obsoleted by the "reference policy"; see
http://serefpolicy.sourceforge.net/
Rawhide should soon be moving to using the reference policy as its
baseline; some experimental packages have been built over at:
ftp://people.redhat.com/dwalsh/SELinux/refpolicy/
This also introduces the use of the binary/loadable policy module
support that is already in rawhide. This should ultimately allow cups
policy to be provided by a separate package from the base policy,
although that decomposition may not happen until later (e.g. after FC5).
Initially, the current policy may just be built as a single monolothic
policy module and the module support may just be used for third party
packages that are not part of the base Fedora.
--
Stephen Smalley
National Security Agency
9:39 a.m.
On Sat, 2005-11-12 at 09:44 -0500, Michael Sweet wrote:
I know some people would prefer to hand-edit all files and place
printer
state data in 5 different places, however no one has proposed an
alternate location for these files that makes sense WRT to the FHS.
We are absolutely committed to making CUPS easy-to-use, which means
allowing programs (in particular cupsd, which can provide finer-grained
authorization/access control to the configuration data than selinux) to
edit those files. CUPS also updates the printers.conf, classes.conf,
and subscriptions.conf files based on (persistent) state changes.
I'm not overly familiar with the specifics of CUPS or its policy myself,
but it would likely help if:
a) the files that need to be writable by cups would be located in a
separate subdirectory from files that should remain read-only (this
allows us to place a distinct type on that subdirectory and have it
inherited by all files re-created in that subdirectory by default, so
that only that type needs to be writable by cups),
b) the functionality for modifying those files could be placed in a
separate helper program executed by cupsd, so that we could run that
helper in a separate domain from cupsd and not give the daemon direct
access to rewriting the files,
c) the helper program in turn supports applying (optional)
filters/checkers to the data so that it can be validated, to prevent it
from being used arbitrarily by a compromised cupsd.
Also, note that SELinux provides an API for application policy enforcers
to support finer-grained controls over application abstractions, and
this API is already being used by dbusd and nscd (and a patch exists for
X, but isn't yet upstream). Hence, it might make sense to look into
using that API from cupsd as well (when running on a SELinux-enabled
system, of course, which you can detect at runtime). That allows you to
then define SELinux policy over those operations in addition to your
existing checks.
--
Stephen Smalley
National Security Agency
10:03 a.m.
Stephen Smalley wrote:
On Sat, 2005-11-12 at 09:44 -0500, Michael Sweet wrote:
> I know some people would prefer to hand-edit all files and place printer
> state data in 5 different places, however no one has proposed an
> alternate location for these files that makes sense WRT to the FHS.
>
> We are absolutely committed to making CUPS easy-to-use, which means
> allowing programs (in particular cupsd, which can provide finer-grained
> authorization/access control to the configuration data than selinux) to
> edit those files. CUPS also updates the printers.conf, classes.conf,
> and subscriptions.conf files based on (persistent) state changes.
I'm not overly familiar with the specifics of CUPS or its policy myself,
but it would likely help if:
a) the files that need to be writable by cups would be located in a
separate subdirectory from files that should remain read-only (this
allows us to place a distinct type on that subdirectory and have it
inherited by all files re-created in that subdirectory by default, so
that only that type needs to be writable by cups),
Technically, all of the files in /etc/cups are configuration files
that can be written by cupsd, even the (usually read-only) MIME
files (*.types and *.convs). CUPS provides an interface for
reading and writing configuration files via HTTP, and that interface
allows for such things as remote configuration and mirroring of all
CUPS configuration data...
b) the functionality for modifying those files could be placed in a
separate helper program executed by cupsd, so that we could run that
helper in a separate domain from cupsd and not give the daemon direct
access to rewriting the files,
That would seriously impact performance and make the code a lot more
complicated. Given that cupsd owns and writes these files, adding
helper apps would have little practical benefit for CUPS 1.2.
We do have plans for supporting alternate storage mechanisms in future
(think CUPS 1.4 or later) so that users can put their configuration
data in a database, version-controlled repository, etc., however we'll
still default to the local, writable files *without* a helper app.
c) the helper program in turn supports applying (optional)
filters/checkers to the data so that it can be validated, to prevent it
from being used arbitrarily by a compromised cupsd.
cupsd already validates its input from configuration files...
Also, note that SELinux provides an API for application policy
enforcers
to support finer-grained controls over application abstractions, and
this API is already being used by dbusd and nscd (and a patch exists for
X, but isn't yet upstream). Hence, it might make sense to look into
using that API from cupsd as well (when running on a SELinux-enabled
system, of course, which you can detect at runtime). That allows you to
then define SELinux policy over those operations in addition to your
existing checks.
I'm not sure that really buys us anything - we already have a system
in place that can be used on all systems and provides remote access
policies above an beyond the UNIX accounts on the system.
Right now I'm more concerned with making the CUPS selinux rules
work with CUPS 1.2, and to clear up any issues so that selinux
does its job and doesn't get in the way of CUPS's job... :)
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
10:14 a.m.
On Tuesday 15 November 2005 03:03, Michael Sweet <mike(a)easysw.com> wrote:
> b) the functionality for modifying those files could be placed
in a
> separate helper program executed by cupsd, so that we could run that
> helper in a separate domain from cupsd and not give the daemon direct
> access to rewriting the files,
That would seriously impact performance and make the code a lot more
complicated. Given that cupsd owns and writes these files, adding
helper apps would have little practical benefit for CUPS 1.2.
Is writing config files really a performance bottleneck? I imagine that for
the majority of the run time of the daemon there are no changes being made to
the configuration.
> Also, note that SELinux provides an API for application policy
enforcers
> to support finer-grained controls over application abstractions, and
> this API is already being used by dbusd and nscd (and a patch exists for
> X, but isn't yet upstream). Hence, it might make sense to look into
> using that API from cupsd as well (when running on a SELinux-enabled
> system, of course, which you can detect at runtime). That allows you to
> then define SELinux policy over those operations in addition to your
> existing checks.
I'm not sure that really buys us anything - we already have a system
in place that can be used on all systems and provides remote access
policies above an beyond the UNIX accounts on the system.
You may (and often will) have multiple programs running with the same Unix UID
but different SE Linux security context. To handle this situation correctly
it is often necessary to have SE Linux support in applications. For example
if we have a printer in a public area and a printer in a secure area we want
to make sure that documents printed at a high MLS sensitivity level can only
go to the printer in the secure area. Implementing this requires that the
CUPS server know about SE Linux access controls. I believe that code is
already being written to implement such functionality.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:37 a.m.
Russell Coker wrote:
On Tuesday 15 November 2005 03:03, Michael Sweet
<mike(a)easysw.com> wrote:
>> b) the functionality for modifying those files could be placed in a
>> separate helper program executed by cupsd, so that we could run that
>> helper in a separate domain from cupsd and not give the daemon direct
>> access to rewriting the files,
> That would seriously impact performance and make the code a lot more
> complicated. Given that cupsd owns and writes these files, adding
> helper apps would have little practical benefit for CUPS 1.2.
Is writing config files really a performance bottleneck? I imagine that for
the majority of the run time of the daemon there are no changes being made to
the configuration.
Since printers.conf, classes.conf, and subscriptions.conf are updated
whenever the configuration or state of a printer, class, or subscription
is updated, it can account for a good amount of time on a busy server
with lots of printers/classes. We've looked at only writing the files
on a server restart/shutdown, however you run into the possibility that
a server crash will lose all of the configuration changes you've made.
Also, when we add that plug-in interface to support alternate storage
mechanisms we'll also be providing information on the user that made
the change (and the nature of the change) to provide important
auditing information, so we'll need to save every change to preserve
that information anyways...
>> Also, note that SELinux provides an API for application
policy enforcers
>> to support finer-grained controls over application abstractions, and
>> this API is already being used by dbusd and nscd (and a patch exists for
>> X, but isn't yet upstream). Hence, it might make sense to look into
>> using that API from cupsd as well (when running on a SELinux-enabled
>> system, of course, which you can detect at runtime). That allows you to
>> then define SELinux policy over those operations in addition to your
>> existing checks.
> I'm not sure that really buys us anything - we already have a system
> in place that can be used on all systems and provides remote access
> policies above an beyond the UNIX accounts on the system.
You may (and often will) have multiple programs running with the same Unix UID
but different SE Linux security context. To handle this situation correctly
it is often necessary to have SE Linux support in applications. For example
if we have a printer in a public area and a printer in a secure area we want
to make sure that documents printed at a high MLS sensitivity level can only
go to the printer in the secure area. Implementing this requires that the
CUPS server know about SE Linux access controls. I believe that code is
already being written to implement such functionality.
Our government customers do not support both secure and non-secure
resources from a single server - it violates the policies they have in
place. Assuming that, at some point, they trust selinux enough to
change those policies and run classified and unclassified processing
on the same system image, you will need to make extensive changes at
both the client and server levels in order to securely pass and
authenticate the document classification data.
In short, CUPS is a network service and supporting such a
configuration would require a lot more work than adding some simple
API hooks which, AFAIK, lack the network scope that is required.
--
______________________________________________________________________
Michael Sweet, Easy Software Products mike at easysw dot com
Internet Printing and Document Software http://www.easysw.com
11:23 a.m.
Michael Sweet wrote:
Our government customers do not support both secure and non-secure
resources from a single server - it violates the policies they have in
place. Assuming that, at some point, they trust selinux enough to
change those policies and run classified and unclassified processing
on the same system image, you will need to make extensive changes at
both the client and server levels in order to securely pass and
authenticate the document classification data.
In short, CUPS is a network service and supporting such a
configuration would require a lot more work than adding some simple
API hooks which, AFAIK, lack the network scope that is required.
I've been meaning to talk to you about that... I've been working on
addressing some of that work. Currently there are three patches against
1.1.23. The initial one was by Cory Olmo from TCS. It provided forced
labels based on the SELinux context of the session that submitted the
print job. I then added some audit hooks to pass information into
Redhat's audit framework. Finally realizing that we wanted to remove
CUPS' dependency on labeled network I did a quick proof of concept patch
which had CUPS use local unix sockets instead of internet sockets.
The initial unix socket patch was compile time and essentially gutted
the sockaddr_in replacing them with sockaddr_un. This is less than
ideal so I was working on a new patch which would combine all three
previous compile times patches into one patch that would make its
decisions at runtime. Using sockaddr_storage and some minimally
invasive logic I was able to get around the need to replicate the
listener_t and http_t data structures. I did end up adding a config
option of "socket" to my development stream since I wanted to make it
distinct from "listen" or "port". I had been planning on allowing
for
"Classification" to be set to selinux in order to specify to use the
SELinux label as the forced banner.
I've since gotten sidetracked off that work so the runtime patch isn't
finished yet. I hope to be able to get back to it in a few weeks. In
the meantime I can send you the patches so you can see first hand the
extent of the damage, and to provide feedback of course ;)
-matt
6739
days inactive
6746
days old
selinux@lists.fedoraproject.org
10 comments
4 participants
participants (4)
-
Matt Anderson -
Michael Sweet -
Russell Coker -
Stephen Smalley