Russell Coker wrote:
On Saturday 12 November 2005 02:47, Michael Sweet <mike@xxxxxxxxxx> 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
--
fedora-selinux-list mailing list
fedora-selinux-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-selinux-list
