From mboxrd@z Thu Jan 1 00:00:00 1970 From: Michael C Thompson Subject: Re: [redhat-lspp] Re: cups userspace -- trusted programs? Date: Thu, 01 Jun 2006 11:29:00 -0500 Message-ID: <447F15CC.4070308@us.ibm.com> References: <447DF735.9090706@us.ibm.com> <447E1EB8.70907@hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <447E1EB8.70907@hp.com> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: linux-audit-bounces@redhat.com Errors-To: linux-audit-bounces@redhat.com To: Linda Knippers Cc: redhat-lspp@redhat.com, Linux Audit List-Id: linux-audit@redhat.com Linda Knippers wrote: > Hi Mike, > > Matt is away this week so he'll probably have a more detailed response > but in the meantime, I have a few comments/questions. > >> I'm wondering if the intent of the cups userspace tools are to be >> trusted programs? Specifically I'm curious about cupsaccept, cupsreject, >> cupsenable and cupsdisable. The reason I ask is because if they are >> supposed to be trusted programs, they don't generate unique audit >> messages like other programs. > > I don't think these programs are trusted programs because all they do > is talk to the cupsd, which is a trusted program. The cupsd makes > all the decisions and takes all the actions. These programs (really > just 'accept' as the rest I believe are symlinks to it) are not setuid > and do not make any access or other decisions, at least that's my > understanding. You are correct. accept, reject, cupsenable and cupsdisable are all done through the accept binary, and it does not responsible for decisions, it only facilitate actions. I learned this after reading some code :p >> Personally, I think these tools should generate messages since they are >> a source for leaking information, and therefore should be restricted to >> administrators. > > I think the real question is which actions should be audited. Should > enabling/disabling a printer queue be audited? I don't believe its > required to be and if its not security relevant, do we want it in the > audit logs? Cups has a comprehensive logging facility so there is all > kinds of information about happening with the print subsystem that I > don't think we want to replicate in the audit logs, but perhaps there > are more actions that would make sense to audit than we currently are > auditing. According to Klaus, this is not strictly speaking required for LSPP. Your point about cups logging such actions is well taken (and over looked by me initially). > Do you have specific examples of actions that you think should be > audited aside from what's required for LSPP? Aside from what is *required*, I thought it would be a good thing to log the queue/printer enable/disable. However, if cups is logging that, I'm not sure it is worth being redundant in our logs. Mike