10:43 a.m.
Here are the four types that were required for Cups
AUDIT_LABELED_EXPORT
AUDIT_UNLABELED_EXPORT
AUDIT_LABEL_OVERRIDE
AUDIT_LABELED_LEVEL_CHANGE
LSPP has the following printing audit requirements:
All attempts to export labeled data
All attempts to export unlabeled data
Overriding the label on a printout
Changing a device from labeled to unlabeled
Changing a device from unlabeled to labeled
Changing the level of a labeled device
-matt
11:10 a.m.
On Wednesday 02 November 2005 11:43, Matt Anderson wrote:
Here are the four types that were required for Cups
AUDIT_LABELED_EXPORT
AUDIT_UNLABELED_EXPORT
Just a generic question -- do we need to patch cat, cp, rsync, scp, star, ...
to have these, too?
What if they do:
file=`cat secret`
echo $file > /mnt/unlabeled-device/file
Would it be reasonable to expect the shell script trigger this event? If so,
would we need to patch all these apps or should this be done via kernel
mechanism? If catching this is reasonable...what about anything else like
perl, python, expect, etc.
AUDIT_LABEL_OVERRIDE
AUDIT_LABELED_LEVEL_CHANGE
These seem to be user space oriented, so I'll add these to libaudit.h.
I think we also need these:
AUDIT_LABELED_IMPORT
AUDIT_UNLABELED_IMPORT
But as to whether they are kernel or userspace message types will depend on
discussing the first paragraph.
-Steve
1:42 p.m.
On Wed, 02 Nov 2005 12:10:42 EST, Steve Grubb said:
On Wednesday 02 November 2005 11:43, Matt Anderson wrote:
>Here are the four types that were required for Cups
>
> AUDIT_LABELED_EXPORT
> AUDIT_UNLABELED_EXPORT
Just a generic question -- do we need to patch cat, cp, rsync, scp, star, ...
to have these, too?
What if they do:
file=`cat secret`
echo $file > /mnt/unlabeled-device/file
Would it be reasonable to expect the shell script trigger this event? If so,
would we need to patch all these apps or should this be done via kernel
mechanism? If catching this is reasonable...what about anything else like
perl, python, expect, etc.
Presumably, that should be failed by SELinux or something as a violation
of the appropriate MLS constraint - a process running at some level allowed
to run 'cat secret' shouldn't be allowed to write to an unlabeled device.
CUPS needs special handling because it acts as a proxy for the user, and also
has to potentially deal with users in different security boxes, so it has to
re-create much of the checking and labelling done by the operating system
when it's the user acting directly.
I think we also need these:
AUDIT_LABELED_IMPORT
AUDIT_UNLABELED_IMPORT
We'll probably eventually need these, but not within the context of CUPS, unless
there's a CUPS facility that can do such importing?
2:14 p.m.
On Wednesday 02 November 2005 14:42, Valdis.Kletnieks(a)vt.edu wrote:
Presumably, that should be failed by SELinux or something as a
violation
of the appropriate MLS constraint - a process running at some level allowed
to run 'cat secret' shouldn't be allowed to write to an unlabeled device.
I think you're missing a subtle point. Assume that the user has the
permissions to read secret and write to an unlabeled media. Assume they have
properly allocated the device and are ready to do something.
Given that, what is the correct action? LSPP says that its an auditable event
- it doesn't say it must be prevented. Should each program that does this be
patched or does a central mechanism in the kernel need to handle this?
-Steve
3:30 p.m.
On Wed, 02 Nov 2005 15:14:15 EST, Steve Grubb said:
On Wednesday 02 November 2005 14:42, Valdis.Kletnieks(a)vt.edu wrote:
> Presumably, that should be failed by SELinux or something as a violation
> of the appropriate MLS constraint - a process running at some level allowed
> to run 'cat secret' shouldn't be allowed to write to an unlabeled
device.
I think you're missing a subtle point. Assume that the user has the
permissions to read secret and write to an unlabeled media. Assume they have
properly allocated the device and are ready to do something.
Given that, what is the correct action? LSPP says that its an auditable event
- it doesn't say it must be prevented. Should each program that does this be
patched or does a central mechanism in the kernel need to handle this?
The point is that we *already* have both audit and MAC (SELinux, etc) capabilities
that are in place to deal with the case where a process is *directly* trying to
export data - audit can see that, and the MAC can prohibit it if it wants to.
The additional CUPS support is because CUPS is acting as a proxy - by the time
we hit the event that LSPP requires support for, the original process may be
long gone (for instance, I may have issued the 'print' command the night before).
6990
days inactive
6990
days old
linux-audit@lists.linux-audit.osci.io
5 comments
4 participants
participants (4)
-
Linda Knippers -
Matt Anderson -
Steve Grubb -
Valdis.Kletnieks＠vt.edu