* cups userspace -- trusted programs?
@ 2006-05-31 20:06 Michael C Thompson
2006-05-31 22:54 ` Linda Knippers
0 siblings, 1 reply; 7+ messages in thread
From: Michael C Thompson @ 2006-05-31 20:06 UTC (permalink / raw)
To: Linux Audit, Linda Knippers, Steve Grubb, mra, redhat-lspp
Hey all,
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.
Personally, I think these tools should generate messages since they are
a source for leaking information, and therefore should be restricted to
administrators.
Thanks,
Mike
--
redhat-lspp mailing list
redhat-lspp@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-lspp
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: cups userspace -- trusted programs?
2006-05-31 20:06 cups userspace -- trusted programs? Michael C Thompson
@ 2006-05-31 22:54 ` Linda Knippers
2006-06-01 16:29 ` [redhat-lspp] " Michael C Thompson
0 siblings, 1 reply; 7+ messages in thread
From: Linda Knippers @ 2006-05-31 22:54 UTC (permalink / raw)
To: Michael C Thompson; +Cc: Steve Grubb, Linux Audit, mra, redhat-lspp
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [redhat-lspp] Re: cups userspace -- trusted programs?
2006-05-31 22:54 ` Linda Knippers
@ 2006-06-01 16:29 ` Michael C Thompson
2006-06-05 18:10 ` Matt Anderson
0 siblings, 1 reply; 7+ messages in thread
From: Michael C Thompson @ 2006-06-01 16:29 UTC (permalink / raw)
To: Linda Knippers; +Cc: redhat-lspp, Linux Audit
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
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Re: cups userspace -- trusted programs?
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
0 siblings, 1 reply; 7+ messages in thread
From: Matt Anderson @ 2006-06-05 18:10 UTC (permalink / raw)
To: Michael C Thompson; +Cc: redhat-lspp, Steve Grubb, Linda Knippers, Linux Audit
Michael C Thompson wrote:
>>> Personally, I think these tools should generate messages since they
>>> are a source for leaking information, and therefore should be
>>> restricted to administrators.
I don't think they should be considered a source for leaking
information. The only thing I see isn't a leak so much as a (extremely
low bandwidth) covert channel of "is the printer enabled or disabled?"
Since the use of these programs is restricted, we're covered under
no-evil-admin.
> 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.
As long as LogLevel is set to info or higher you'll get a message in
/var/log/cups/error_log like:
[Timestamp] Printer 'foo' stopped by 'root'.
I think I agree with you that its probably not worth being redundant,
but if for someone finds a requirement for this to go to the audit log I
don't see any issues around adding that.
-matt
--
redhat-lspp mailing list
redhat-lspp@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-lspp
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Re: cups userspace -- trusted programs?
2006-06-05 18:10 ` Matt Anderson
@ 2006-06-05 18:25 ` Michael C Thompson
2006-06-05 18:53 ` [redhat-lspp] " Linda Knippers
0 siblings, 1 reply; 7+ messages in thread
From: Michael C Thompson @ 2006-06-05 18:25 UTC (permalink / raw)
To: Matt Anderson; +Cc: redhat-lspp, Steve Grubb, Linda Knippers, Linux Audit
Matt Anderson wrote:
> Michael C Thompson wrote:
>>>> Personally, I think these tools should generate messages since they
>>>> are a source for leaking information, and therefore should be
>>>> restricted to administrators.
>
> I don't think they should be considered a source for leaking
> information. The only thing I see isn't a leak so much as a (extremely
> low bandwidth) covert channel of "is the printer enabled or disabled?"
> Since the use of these programs is restricted, we're covered under
> no-evil-admin.
How are these restricted? Or rather, how are they supposed to be
restricted? I am able to cupsenable, cupsdisable, accept and reject my
printer as a non-root user under both permissive and enforcing modes.
>> 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.
>
> As long as LogLevel is set to info or higher you'll get a message in
> /var/log/cups/error_log like:
>
> [Timestamp] Printer 'foo' stopped by 'root'.
>
> I think I agree with you that its probably not worth being redundant,
> but if for someone finds a requirement for this to go to the audit log I
> don't see any issues around adding that.
>
> -matt
--
redhat-lspp mailing list
redhat-lspp@redhat.com
https://www.redhat.com/mailman/listinfo/redhat-lspp
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [redhat-lspp] Re: cups userspace -- trusted programs?
2006-06-05 18:25 ` Michael C Thompson
@ 2006-06-05 18:53 ` Linda Knippers
2006-06-05 19:29 ` Michael C Thompson
0 siblings, 1 reply; 7+ messages in thread
From: Linda Knippers @ 2006-06-05 18:53 UTC (permalink / raw)
To: Michael C Thompson; +Cc: redhat-lspp, Linux Audit
>> I don't think they should be considered a source for leaking
>> information. The only thing I see isn't a leak so much as a
>> (extremely low bandwidth) covert channel of "is the printer enabled
>> or disabled?" Since the use of these programs is restricted, we're
>> covered under no-evil-admin.
>
> How are these restricted? Or rather, how are they supposed to be
> restricted? I am able to cupsenable, cupsdisable, accept and reject
> my printer as a non-root user under both permissive and enforcing
> modes.
To which groups does your user account belong? By default, cups
will allow anyone in group sys to perform administrative functions
but this is configurable in cupsd.conf. We'll have to decide
whether allowing sys group members is ok or we'll have to modify
the cupsd.conf for the evaluated config. I suspect we'll modify
cupsd.conf.
-- ljk
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: [redhat-lspp] Re: cups userspace -- trusted programs?
2006-06-05 18:53 ` [redhat-lspp] " Linda Knippers
@ 2006-06-05 19:29 ` Michael C Thompson
0 siblings, 0 replies; 7+ messages in thread
From: Michael C Thompson @ 2006-06-05 19:29 UTC (permalink / raw)
To: Linda Knippers; +Cc: redhat-lspp, Linux Audit
Linda Knippers wrote:
>>> I don't think they should be considered a source for leaking
>>> information. The only thing I see isn't a leak so much as a
>>> (extremely low bandwidth) covert channel of "is the printer enabled
>>> or disabled?" Since the use of these programs is restricted, we're
>>> covered under no-evil-admin.
>>
>> How are these restricted? Or rather, how are they supposed to be
>> restricted? I am able to cupsenable, cupsdisable, accept and reject
>> my printer as a non-root user under both permissive and enforcing
>> modes.
>
> To which groups does your user account belong?
uid=500(mcthomps) gid=500(mcthomps) groups=500(mcthomps)
context=user_u:user_r:user_t:SystemLow
> By default, cups
> will allow anyone in group sys to perform administrative functions
> but this is configurable in cupsd.conf. We'll have to decide
> whether allowing sys group members is ok or we'll have to modify
> the cupsd.conf for the evaluated config. I suspect we'll modify
> cupsd.conf.
I've butchered my cupsd.conf pretty badly, so it could be a result of
that. I've not tried doing this with a fresh install, but if it works on
your end, I'll assume it's my config mangling.
Mike
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2006-06-05 19:29 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-05-31 20:06 cups userspace -- trusted programs? Michael C Thompson
2006-05-31 22:54 ` Linda Knippers
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
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox