Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Eamon Walsh wrote:
Daniel J Walsh wrote:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Daniel J Walsh wrote:
What are these doing? Why do I need these?
type_transition $2_t default_xproperty_t:x_property
$2_default_xproperty_t;
type_transition $2_t property_xevent_t:x_event $2_property_xevent_t;
type_transition $2_t focus_xevent_t:x_event $2_focus_xevent_t;
type_transition $2_t manage_xevent_t:x_event $2_manage_xevent_t;
type_transition $2_t default_xevent_t:x_event $2_default_xevent_t;
Looking at this further, I think these should be classes.
allow staff_t self:property_xevent_t send;
Have all xevent with the same class is similar to having blk_file,
chr_file, sock_file all class file and defining transitions.
This makes sense, and it's something I considered, however I couldn't
get the set of classes nailed down firmly enough to make a decision. The
class structure was too rigid, in my opinion, to support this kind of
categorization.
It's even worse with window properties, which are based on an open-ended
namespace. All kinds of zany conventions have been established
regarding the use of this or that property, and who knows what other
ones might come along.
But are any of these worth anything from a security perspective? Are we
adding huge complexity for any reason. Is xevent enough or x_property
in most cases. If I can set one x_property will I need to set them all.
I hate type explosions, because it just generates AVC errors and
unexpected errors.
The two properties that hold the selinux contexts should be read-only to
everyone since only the server sets them. Actually I'm going to
deprecate these shortly in favor of the GetWindowContext X protocol
request anyway. If you don't care about the others, just collapse them
down to one type and transition them to staff_f in your policy. The
stuff that is there now is an example of how you might separate window
hint properties from globally writable properties like the cut buffers.
For events, too, you could probably collapse them down to staff_t.
Again, the stuff that is there now is an example of how to separate
input events, property notify events, and other types of event. Other
people doing stricter separation might need this functionality.
I think we should think of the interactions we are trying to stop and
then only generate the types necessary to prevent these interactions.
If all we want to stop is
cut/paste
screencapture
keyboard sniffing
focus grab
...
Lets build up the limited types to control this interaction.
Another way to look at it would be the way we have labeled /proc. We
only add a new type when there is a justifiable security difference.
I want to refer to all of the XClass via the main type.
Lets take an example.
I write policy for all X Apps that staff_t runs without a transition to
stay staff_t.
Now I write a transition rule for staff_mozilla_t.
So I want to say something like
xserver_paste_pattern(staff_mozilla_t, staff_t)
I would like to then write something like
allow staff_mozilla_t staff_t:x_property read;
But you make me write.
allow staff_mozilla_t staff_default_x_property_t:x_property read;
Which screws up the interface and I end up having to pass around staff
and staff_mozilla.
Is this necessary?
Is this legal?
type_transition $2_t input_xevent_t:x_event $2_t;
Or is it even necessary?
I really want to build an interface that says
xserver_application(staff, staff_t)
xserver_application(staff, staff_mozilla_t)
Then define any interactions between staff_t and staff_mozilla_t via
simple interfaces.
If you're already passing (staff, staff_t) around then why not just pass
the prefixes to your interaction function?
xserver_interact(staff, staff_t, staff_mozilla, staff_mozilla_t)
doesn't look that bad to me.
It's not my fault that we have all these complex constructions just to
make sure everything has a "_t" on the end of it.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkfNU9oACgkQrlYvE4MpobPAuQCdHLMeuE+kSpfNyNYQ+jzjsyO5
UUoAn2Pxu030f6iGOCgTc79DY0NFwVm3
=j+HT
-----END PGP SIGNATURE-----
--
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.
--
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.
