Re: copy&paste security_compute_av from python

Re: copy&paste security_compute_av from python

[Eamon Walsh]

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?

> Dan have you ever called security_compute_av from Python?
>
> Ted
>
>   


-- 
Eamon Walsh <ewalsh@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: copy&paste security_compute_av from python

[Stephen Smalley]

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

-- 
Stephen Smalley
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: copy&paste security_compute_av from python

[Eamon Walsh]

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@tycho.nsa.gov>
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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: copy&paste security_compute_av from python

[Xavier Toth]

On Wed, Apr 9, 2008 at 1:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>
>  On Wed, 2008-04-09 at 14:13 -0400, Eamon Walsh wrote:
>  > Xavier Toth wrote:
>  > > Also what about the mlsconstrain(s):
>  > >
>  > > #
>  > > # MLS policy for the x_application_data class
>  > > #
>  > > mlsconstrain x_application_data { paste_after_confirm }
>  > >     (( l1 eq l2 ) or
>  > >      (( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
>  > >      ( t1 == mlsxwinwrite ));
>  > >
>  > >
>  > > ??
>  > >
>  >
>  > I dunno.  Configure to suit your environment.  This is for write-downs,
>  > correct?  If so then you probably don't want any constraints, since
>  > regular "paste" should succeed in the write-up case (in which case no
>  > confirmation is required), and the point of this permission is to allow
>  > write downs.
>  >
>  > >
>  > > On Tue, Apr 8, 2008 at 1:50 PM, Xavier Toth <txtoth@gmail.com> wrote:
>  > >
>  > >> I'd prefer copy instead cut.
>  > >>
>  >
>  > This is fine.
>  >
>  > My work on the XCB Python binding is coming along OK.  I see that you
>  > are working on Python bindings for the userspace AVC.  That's fine, but
>  > you could probably get away with not using the AVC in the selection
>  > manager.  You could simply look up the permission and class values in
>  > /selinux, then use security_compute_create for permission checking.
>  > Since the selection manager is driven by user clicking, performance
>  > shouldn't be that big of a deal.
>
>  security_compute_av().
>  But then he loses out on the libselinux infrastructure for things like
>  permissive mode, mapping the class/perm values internally for him, etc.
>  I think using the AVC interface is best whenever possible.
>
>

This is what I'd prefer also and I was hoping Dan would add the avc
header so that the avc interface bindings would get built into
_selinux.so.

>
>  --
>  Stephen Smalley
>  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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: copy&paste security_compute_av from python

[Daniel J Walsh]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Xavier Toth wrote:
> On Wed, Apr 9, 2008 at 1:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>>  On Wed, 2008-04-09 at 14:13 -0400, Eamon Walsh wrote:
>>  > Xavier Toth wrote:
>>  > > Also what about the mlsconstrain(s):
>>  > >
>>  > > #
>>  > > # MLS policy for the x_application_data class
>>  > > #
>>  > > mlsconstrain x_application_data { paste_after_confirm }
>>  > >     (( l1 eq l2 ) or
>>  > >      (( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
>>  > >      ( t1 == mlsxwinwrite ));
>>  > >
>>  > >
>>  > > ??
>>  > >
>>  >
>>  > I dunno.  Configure to suit your environment.  This is for write-downs,
>>  > correct?  If so then you probably don't want any constraints, since
>>  > regular "paste" should succeed in the write-up case (in which case no
>>  > confirmation is required), and the point of this permission is to allow
>>  > write downs.
>>  >
>>  > >
>>  > > On Tue, Apr 8, 2008 at 1:50 PM, Xavier Toth <txtoth@gmail.com> wrote:
>>  > >
>>  > >> I'd prefer copy instead cut.
>>  > >>
>>  >
>>  > This is fine.
>>  >
>>  > My work on the XCB Python binding is coming along OK.  I see that you
>>  > are working on Python bindings for the userspace AVC.  That's fine, but
>>  > you could probably get away with not using the AVC in the selection
>>  > manager.  You could simply look up the permission and class values in
>>  > /selinux, then use security_compute_create for permission checking.
>>  > Since the selection manager is driven by user clicking, performance
>>  > shouldn't be that big of a deal.
>>
>>  security_compute_av().
>>  But then he loses out on the libselinux infrastructure for things like
>>  permissive mode, mapping the class/perm values internally for him, etc.
>>  I think using the AVC interface is best whenever possible.
>>
>>
> 
> This is what I'd prefer also and I was hoping Dan would add the avc
> header so that the avc interface bindings would get built into
> _selinux.so.
> 
>>  --
>>  Stephen Smalley
>>  National Security Agency
>>
>>
Most of the avc.h will not work without a lot of work.  Which interfaces
do you need?  If the interfaces take a struct, we probably would need to
write a lot of binding code.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org

iEYEARECAAYFAkf+RbgACgkQrlYvE4MpobOwlgCggooBGCaUN1IHv54VdDhrYSxe
HokAoMGbjUvRsoFdGVOgVcUkBw0r+6NW
=ssmU
-----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.

Re: copy&paste security_compute_av from python

[Xavier Toth]

avc_has_perm and avc_context_to_sid_raw which don't require structs

On Thu, Apr 10, 2008 at 11:52 AM, Daniel J Walsh <dwalsh@redhat.com> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>  Xavier Toth wrote:
>
>
> > On Wed, Apr 9, 2008 at 1:28 PM, Stephen Smalley <sds@tycho.nsa.gov> wrote:
>  >>  On Wed, 2008-04-09 at 14:13 -0400, Eamon Walsh wrote:
>  >>  > Xavier Toth wrote:
>  >>  > > Also what about the mlsconstrain(s):
>  >>  > >
>  >>  > > #
>  >>  > > # MLS policy for the x_application_data class
>  >>  > > #
>  >>  > > mlsconstrain x_application_data { paste_after_confirm }
>  >>  > >     (( l1 eq l2 ) or
>  >>  > >      (( t1 == mlsxwinwritetoclr ) and ( h1 dom l2 ) and ( l1 domby l2 )) or
>  >>  > >      ( t1 == mlsxwinwrite ));
>  >>  > >
>  >>  > >
>  >>  > > ??
>  >>  > >
>  >>  >
>  >>  > I dunno.  Configure to suit your environment.  This is for write-downs,
>  >>  > correct?  If so then you probably don't want any constraints, since
>  >>  > regular "paste" should succeed in the write-up case (in which case no
>  >>  > confirmation is required), and the point of this permission is to allow
>  >>  > write downs.
>  >>  >
>  >>  > >
>  >>  > > On Tue, Apr 8, 2008 at 1:50 PM, Xavier Toth <txtoth@gmail.com> wrote:
>  >>  > >
>  >>  > >> I'd prefer copy instead cut.
>  >>  > >>
>  >>  >
>  >>  > This is fine.
>  >>  >
>  >>  > My work on the XCB Python binding is coming along OK.  I see that you
>  >>  > are working on Python bindings for the userspace AVC.  That's fine, but
>  >>  > you could probably get away with not using the AVC in the selection
>  >>  > manager.  You could simply look up the permission and class values in
>  >>  > /selinux, then use security_compute_create for permission checking.
>  >>  > Since the selection manager is driven by user clicking, performance
>  >>  > shouldn't be that big of a deal.
>  >>
>  >>  security_compute_av().
>  >>  But then he loses out on the libselinux infrastructure for things like
>  >>  permissive mode, mapping the class/perm values internally for him, etc.
>  >>  I think using the AVC interface is best whenever possible.
>  >>
>  >>
>  >
>  > This is what I'd prefer also and I was hoping Dan would add the avc
>  > header so that the avc interface bindings would get built into
>  > _selinux.so.
>  >
>  >>  --
>  >>  Stephen Smalley
>  >>  National Security Agency
>  >>
>  >>
>  Most of the avc.h will not work without a lot of work.  Which interfaces
>  do you need?  If the interfaces take a struct, we probably would need to
>  write a lot of binding code.
>
> -----BEGIN PGP SIGNATURE-----
>  Version: GnuPG v1.4.9 (GNU/Linux)
>  Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
>
>  iEYEARECAAYFAkf+RbgACgkQrlYvE4MpobOwlgCggooBGCaUN1IHv54VdDhrYSxe
>  HokAoMGbjUvRsoFdGVOgVcUkBw0r+6NW
>  =ssmU
>  -----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@tycho.nsa.gov with
the words "unsubscribe selinux" without quotes as the message.