Re: UIPermission Clipboard

From: Nicole Calinoiu (calinoiu)
Date: 04/20/05


Date: Wed, 20 Apr 2005 08:54:21 -0400


"Alan Dean" <adeanRemoveThisText@hotmail.com> wrote in message
news:uZ1MQoZRFHA.2252@TK2MSFTNGP15.phx.gbl...
> Nicole,
>
> Thanks for the feedback. So the problem is the lack of a security demand
> when calling the clipboard, which stymies me.

The documentation for the Clipboard.SetObjectData method states that
UIPermission\AllClipboard is required, which means that the method ought to
demand the permission. I can't find any additional documentation to suggest
whether the problem lies in the implementation or the documentation.
Personally, I can't see any reason why a write-time demand shouldn't be
used, so I would tend to lean toward it being a bug in the implemenation,
but someone at Microsoft might have a different opinion on the subject...
<g>

> The reason for seeking the security excpetion was to mitigate the risk of
> third-party software using my components for an exploit (e.g. a luring
> attack). I'm working through all of the permission objects trying to find
> the most secure attribute set to cause security exceptions even when fully
> trusted. Then, as I add functionality I can gradually relax the attribute
> set as needed.

Unfortunately, given the lack of demand in the Clipboard.SetObjectData, the
usual approaches for luring prevention won't work here. Given this, the
best you can do is probably the following:

1. If your assembly doesn't need to write to the clipboard:
    a. Don't include any code in it that does write to the clipboard.
    b. Reject all clipboard permissions via assembly-level attributes.
Even though this will have no effect on the current framework version, it
will kick in if the lack of demand is a bug that eventually gets fixed.

2. If your assembly does need to write to the clipboard, implement a method
demands UIPermission\AllClipboard prior to calling Clipboard.SetObjectData,
and perform all of your own clipboard writes via this method. At least with
this approach, potential lurers will have greater difficulty getting your
code to perform a direct write to the clipboard.

>
> Regards,
> Alan Dean
>
>
> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in message
> news:encCbfZRFHA.3296@TK2MSFTNGP15.phx.gbl...
>> "Alan Dean" <adeanRemoveThisText@hotmail.com> wrote in message
>> news:egru4XZRFHA.2348@tk2msftngp13.phx.gbl...
>>> Nicole,
>>>
>>> Unfortunately, this doesn't help - if you are running under Full Trust
>>> then the demand will succeed because "All callers higher in the call
>>> stack are required to have been granted the permission specified by the
>>> current permission object".
>>
>> Sorry, I thought you were just trying to figure out why the demand didn't
>> seem to be evaluated.
>>
>>
>>> I want to cause a security exception to be encountered even if the call
>>> stack has the rights to access the clipboard.
>>
>> Since the Clipboard class doesn't demand any subset of UIPermission when
>> writing to the clipboard, no refusals, denials, or permit-onlies on the
>> part of your code will have any effect. If you don't want your code
>> writing to the clipboard, why not simply exclude any clipboard-writing
>> from your assembly?
>>
>>
>>> I can achieve this with other Permission attributes, for example I can
>>> cause a security exception when trying to print even if I have the
>>> rights by adding this attribute:
>>>
>>> [assembly:PrintingPermission(SecurityAction.RequestRefuse,
>>> Level=PrintingPermissionLevel.AllPrinting)]
>>
>> That's because the PrintController.Print method makes a demand for
>> PrintingPermission. If Clipboard.SetDataObject made a demand for
>> UIPermission, a refusal of the demanded permission would prevent writing
>> to the clipboard via that method.
>>
>>
>>>
>>> Regards,
>>> Alan Dean
>>> email: adeanRemoveThisText@hotmail.com
>>> blog: http://www.dotnetjunkies.com/weblog/alan.dean/
>>>
>>>
>>> "Nicole Calinoiu" <calinoiu REMOVETHIS AT gmail DOT com> wrote in
>>> message news:euifoOZRFHA.3664@TK2MSFTNGP15.phx.gbl...
>>>> The Clipboard.SetDataObject does not demand any CAS permissions, at
>>>> least in .NET Framework v. 1.1 SP1. If you want to force a demand via
>>>> your own code, one approach would be to add a demand for
>>>> UIPermission\Clipboard on your SecureClipboard.SetData method. e.g.:
>>>>
>>>> [UIPermission(SecurityAction.Demand, Clipboard =
>>>> UIPermissionClipboard.AllClipboard)]
>>>> public static void SetData()
>>>> {
>>>> Clipboard.SetDataObject("Hello World!", true);
>>>> }
>>>>
>>>> HTH,
>>>> Nicole
>>>>
>>>>
>>>> "Alan Dean" <adeanRemoveThisText@hotmail.com> wrote in message
>>>> news:eTTDuFURFHA.3704@TK2MSFTNGP12.phx.gbl...
>>>>> Hi,
>>>>>
>>>>> I'm hoping that someone can assist me. I'm trying to set code access
>>>>> security to prevent an application interacting with the Clipboard.
>>>>>
>>>>> Seemingly, it should be a relatively straightforward setting to apply
>>>>> but I can't seem to get the setting correct - no matter what
>>>>> configuration of attribute I craft up, which has me very confused...
>>>>>
>>>>> Assembly attributes that I have tried:
>>>>> ------------------------------------
>>>>> [assembly:UIPermission(SecurityAction.RequestRefuse,
>>>>> Clipboard=UIPermissionClipboard.NoClipboard)]
>>>>>
>>>>> I've tried every combination of {SecurityAction.RequestRefuse |
>>>>> SecurityAction.RequestOptional | SecurityAction.RequestMinimum} with
>>>>> every combination of {UIPermissionClipboard.NoClipboard |
>>>>> UIPermissionClipboard.OwnClipboard |
>>>>> UIPermissionClipboard.AllClipboard} and with {Unrestricted=true |
>>>>> Unrestricted=false}
>>>>>
>>>>> Class / Method attributes that I have tried:
>>>>> ------------------------------------------
>>>>> [UIPermission(SecurityAction.PermitOnly,
>>>>> Clipboard=UIPermissionClipboard.NoClipboard)]
>>>>>
>>>>> I've tried every combination of {SecurityAction.Assert |
>>>>> SecurityAction.Demand | SecurityAction.Deny |
>>>>> SecurityAction.LinkDemand | SecurityAction.PermitOnly} with every
>>>>> combination of {UIPermissionClipboard.NoClipboard |
>>>>> UIPermissionClipboard.OwnClipboard |
>>>>> UIPermissionClipboard.AllClipboard} and with {Unrestricted=true |
>>>>> Unrestricted=false}
>>>>>
>>>>>
>>>>> This is the code that I applied the attributes to - but I couldn't get
>>>>> any combination to throw a security exception ...
>>>>>
>>>>> using System;
>>>>> using System.Security;
>>>>> using System.Security.Permissions;
>>>>> using System.Windows.Forms;
>>>>>
>>>>> namespace UIPermissionSpike
>>>>> {
>>>>> class App
>>>>> {
>>>>> [STAThread] static void Main(string[] args)
>>>>> {
>>>>> try
>>>>> {
>>>>> SecureClipboard.SetData();
>>>>> }
>>>>> catch (SecurityException securityException)
>>>>> {
>>>>> Console.WriteLine(securityException.Message);
>>>>> Console.ReadLine();
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>> public sealed class SecureClipboard
>>>>> {
>>>>> private SecureClipboard()
>>>>> { }
>>>>>
>>>>> public static void SetData()
>>>>> {
>>>>> Clipboard.SetDataObject("Hello World!", true);
>>>>> }
>>>>> }
>>>>> }
>>>>>
>>>>>
>>>>
>>>>
>>>
>>>
>>
>>
>
>



Relevant Pages

  • Re: UIPermission Clipboard
    ... So the problem is the lack of a security demand ... I'm working through all of the permission objects trying to find ... >> stack has the rights to access the clipboard. ...
    (microsoft.public.dotnet.security)
  • Re: UIPermission Clipboard
    ... > are required to have been granted the permission specified by the current ... I thought you were just trying to figure out why the demand didn't ... > stack has the rights to access the clipboard. ...
    (microsoft.public.dotnet.security)
  • Re: security exception for aspx page
    ... permission that is being demanded is. ... demand is called so that the stack walk is stopped (note, ... - Create your own assembly that goes in the GAC that wraps their assembly ...
    (microsoft.public.dotnet.security)
  • about permissions
    ... Assert vs Demand ... With assert, the immediate caller must have permission to ...
    (microsoft.public.cert.exam.mcad)
  • Re: When to explicitly check permission
    ... > SecurityException instead would there? ... Directory.GetCurrentDirectory method will implement a demand for ... > should I do an explicit check my self before I call the method? ... performing a preliminary demand for the same permission. ...
    (microsoft.public.dotnet.security)