From: Michael C Thompson <thompsmc@us.ibm.com>
To: Linda Knippers <linda.knippers@hp.com>
Cc: redhat-lspp@redhat.com, Linux Audit <linux-audit@redhat.com>
Subject: Re: [redhat-lspp] Re: cups userspace -- trusted programs?
Date: Thu, 01 Jun 2006 11:29:00 -0500 [thread overview]
Message-ID: <447F15CC.4070308@us.ibm.com> (raw)
In-Reply-To: <447E1EB8.70907@hp.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
next prev parent reply other threads:[~2006-06-01 16:29 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-05-31 20:06 cups userspace -- trusted programs? Michael C Thompson
2006-05-31 22:54 ` Linda Knippers
2006-06-01 16:29 ` Michael C Thompson [this message]
2006-06-05 18:10 ` Matt Anderson
2006-06-05 18:25 ` Michael C Thompson
2006-06-05 18:53 ` [redhat-lspp] " Linda Knippers
2006-06-05 19:29 ` Michael C Thompson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=447F15CC.4070308@us.ibm.com \
--to=thompsmc@us.ibm.com \
--cc=linda.knippers@hp.com \
--cc=linux-audit@redhat.com \
--cc=redhat-lspp@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.