Re: Security - Permissions Configuration

From: UAError (null_at_null.null)
Date: 10/27/04 

Date: Wed, 27 Oct 2004 13:15:46 -0400

"Angelos Karantzalis" <akarantzalis@agiltech.gr> wrote:

>.. I'll just have to do it myself then :D
>

You're still in the danger of reinventing the wheel and
,worse, creating yet another application that requires
administrator privileges to run.

>You're building an application, which supports services in the form of
>dynamically downloaded plugins.

OK standard users are often denied the privilege to
"install" anything. A downloaded .NET assembly can be
downloaded and run in a "sandbox" but it still is configured
by CAS to the "Internet" Permission set and that doesn't
allow much.

You can however get the "client" too install code groups and
permission sets that match your code through membership
conditions to grant your assembly(ies) permissions beyond
the ones found in the "Internet" permission set. However
these must at least be present on the Enterprise level
Security policy (marked as LevelFinal) which can only be
done by an administrator. If its not marked as "LevelFinal",
the code groups/permission sets will also have to be present
on the User level Security Policy and Machine level Security
Policy.

But ultimately CAS cannot grant more rights than the user
already has under Windows.

>You can expect that more than one users will
>be using the same installation. Some of those plugins though, need the user
>has special authorization (role) to run, others don't.
 
This is were you are not specific enough - (A) does your
application not want them to have access to an application
feature or (B) is there a platform resource that the user
does not have access too.

if (A) then you need to implement you own RBS most likely
with GenericIdentity and GenericPrincipal.

if (B) let Windows Security handle it; .NET will generate an
exception. If you want to be able to disable features in the
absence of access rights use WindowsPrincipal.IsInRole - the
Windows Group can be one you created on the machine or in
the domain for the purposes of your application - existing
users will then simply have to be assigned windows group
memberships pertinent to your application.

>To complicate the
>matter a bit further, you can execute the plugin under a "login domain" -
>you have multiple login domains in the app, and each time you try to do
>anything, you do it under a login domain, a "context" if you will ... ,

This is were you lose me - I think there's breakdown of
communication here. To me a username that is valid in
multiple network domains still are multiple distinct
"users". I don't know what concept you are trying to convey
with "login domains".

However under windows it is possible for a windows user to
run an application as a different user and have certain
parts of the application run as a differrent user through
the use of impersonation (provided the necessary credentials
are present).

But even that privilege can be denied. To impersonate you
have to have the
    SeTcbPrivilege "Act as part of the operating system"
                    (TCB = Trusted Computing Base)

privilege. This has been changed in .NET Server 2003 which
has:
    SeImpersonatePrivilege "Impersonate a client after
authentication"

to close that vulnerabilty.

> and
>the plugins are shared between domains. But you need different roles to use
>them under each domain ...

Relevant Pages