Stephen Smalley wrote:
On Mon, 2008-03-31 at 20:42 -0400, Eamon Walsh wrote:
Xavier Toth wrote:
I'm working on the code for the selection request where I've got the
source context and the destination context and I've got to decide if I
need to popup the downgrade dialog. The class for the
security_compute_av call should probably be SECCLASS_PROPERTY, right?
But what about the av bits?
If we want to use a permission check in the selection manager
application to decide whether to pop up the confirmation dialog, then I
think we need a new security class to express the concept of "clipboard
data". The existing set of classes and permissions is oriented towards
the low-level mechanics of the X selection mechanism: the individual
property objects where data is written and the selection objects that
are used for the IPC. Neither of those really captures the notion of
actually reading or writing the clipboard data itself.
This concept is already implemented in the X server; you can call
SetSelectionCreateContext to set a context on the "data" when you take
ownership of a selection, and the GetSelectionDataContext request
returns this context for the current selection owner. The server itself
doesn't perform any checks on this data context at present.
But, is there a different way to decide whether the paste operation
would be a downgrade? Some type of context dominance call?
Just define a permission for it, and then you can define a mls
constraint on it to express the requirement that downgrades require a
particular type attribute.
Somewhat analogous is that pam and sshd apply a context:contains
permission check these days to see if selected level falls within the
user's authorized range (since the authorized range information for
Linux users is maintained in seusers and is not directly defined by the
kernel policy).
It's a little more complicated because there are three possibilities:
deny the paste, allow the paste, or allow the paste after user confirmation.
How about the following security class:
class x_application_data {
read
read_after_confirm
write
}
The selection manager would have to do two checks, first on read then on
read_after_confirm, if the former succeeds the paste goes through, if
the latter succeeds the user must confirm, otherwise the paste is
disallowed.
--
Eamon Walsh <ewalsh@xxxxxxxxxxxxx>
National Security Agency
--
This message was distributed to subscribers of the selinux mailing list.
If you no longer wish to subscribe, send mail to majordomo@xxxxxxxxxxxxx with
the words "unsubscribe selinux" without quotes as the message.
