Eduardo Madeira Fleury wrote: > On Wednesday 15 November 2006 20:01, Matt Anderson wrote: > >> I still need to look through the updated cups policy. In my testing on >> selinux-policy-mls 2.4.3-13 I'm still not seeing the behavior I'm >> expecting so I need to look at the source and put a patch together to >> send to Dan Walsh. >> > > Hi Matt! > > I'd like to know what's the current status of CUPS. Are you being able to > make > it work in enforcing?
Other than the issues you've raised here the only other thing I've become aware of is when an auid is not available the client utilities will block. Seems to me that they should return an error. > I've realized that currently a user is being able to list jobs sent by other > users that belong to the same level using "lpstat all". SELinux is blocking > other roles but it seems the MAC permissions are not being enforced. This appears to be the side effect of what went in for bug #213498. As a result of that fix the MLS checks are not occurring when a user lists the queue. > Finally, are you being able to setup File Device printers? I've enabled them > in cupsd.conf, adding a file device printer works well but I'm not able to > print to them because Lpr says it can't get the SELinux permissions on that > file. Are you aware of that? There was a fix related to this (bug #216855) that enabled FileDevice printers. In testing what you mentioned above it seems that if the file device file does not exists prior to attempting to print to it then the action is blocked. In certain cases even when it does exist cupsd is not allowed to stat() the target file. The error handling for that case needs to be improved. The main problem here is that if the file does not exist, then the cups file backend needs to create it. I can add the logic to the file backend to adjust the level and type of the file as necessary, or we can document that in order to print to a file you must first `touch` that file. I prefer the latter since although the level the file will be obvious from the client's context the type will not be. user_lpr_t is a typical type for the client, and while the user would be able to read that output it still seems like the wrong type to me. If there are objections, or if someone knows of a good way to determine what type the output should be then I can do that, but for now creating the file before printing to it seems better to me. I will finish putting together an updated patch that addresses these issues and send that to Redhat. -matt -- redhat-lspp mailing list [email protected] https://www.redhat.com/mailman/listinfo/redhat-lspp
