Linux-audit Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Linda Knippers <linda.knippers@hp.com>
To: Michael C Thompson <thompsmc@us.ibm.com>
Cc: Steve Grubb <sgrubb@redhat.com>,
	Linux Audit <linux-audit@redhat.com>,
	mra@hp.com, redhat-lspp@redhat.com
Subject: Re: cups userspace -- trusted programs?
Date: Wed, 31 May 2006 18:54:48 -0400	[thread overview]
Message-ID: <447E1EB8.70907@hp.com> (raw)
In-Reply-To: <447DF735.9090706@us.ibm.com>

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.

> 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.

Do you have specific examples of actions that you think should be
audited aside from what's required for LSPP?

-- ljk
> 
> Thanks,
> Mike
> 

--
redhat-lspp mailing list
redhat-lspp@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-lspp

  reply	other threads:[~2006-05-31 22:54 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 [this message]
2006-06-01 16:29   ` [redhat-lspp] " Michael C Thompson
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=447E1EB8.70907@hp.com \
    --to=linda.knippers@hp.com \
    --cc=linux-audit@redhat.com \
    --cc=mra@hp.com \
    --cc=redhat-lspp@redhat.com \
    --cc=sgrubb@redhat.com \
    --cc=thompsmc@us.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox