Scott Dier wrote:

>On Thu, 2002-08-08 at 16:21, Richard Hoffbeck wrote:
>
>  
>
>>stock Linux install, how do I share a file I own with Bill and Mary 
>>without going through root to create a group with two users?
>>    
>>
>
>Groups still don't get created on a AD without administrator help. 
>Minimally a Trusted User handles those with a delegation of part of the
>active directory.  Sanely, only specific groups are delegated to avoid
>major systems design issues.  So sure, lets assume that the addition and
>removal of users in a group is now delegated, (Yeah, right, like anyone
>is going to manage ACLs of specific dispersed files of all users)
>however the creation and design of groups (domain or globally) are still
>the responsibility of an administrator at the OU, domain, or global tree
>level.  Unless a whole OU is just given out to a very trusted user for
>those sorts of things (creating groups), but that would scare too many
>administrators worth their salt worrying about a sustainable system in
>the future.  
>  
>
You're right about the group creation - it was a bad example on my part. 
A better example would have been the simple case where I want to permit 
access to a file for a specific user, or different access to the same 
file to several different users. On system that support ACL's, including 
the Windows Domain model, the owner of the file can change the security 
on the object if they have privileges to manage their own objects.  

>I also fear giving this sort of 'power' to people in positions that
>aren't responsible for data security (if applicable, HIPPA might make it
>a PITA for administrators to give this up in some environs) or for the
>power structure of the 'system' to be seperate from the actual 'power
>structure' in some ways to avoid stupid-user-battles.  Of course, the
>latter could easily be worked out with decent event logging and
>auditing. (Perhaps forwarding the audit logs to said users bosses to
>mitigate evil blame from them if something stupid does happen.) 
>Delegating control can be a powerful tool, but I believe it can, in many
>cases, become more of a pain and a liability of 'image' to 'higher ups'
>when stuff happens.  There's something to be said about being directly
>responsibile.
>  
>
I agree completely - especially that HIPPA is going be to one of those 
'you may experience some slight discomfort' momements. But many large 
corporations already have distributed responsibility for their security 
administration where someone in HR can grant/revoke some privileges. 
Someone in finance manages access to financial applications Someone in 
IT manages access to the e-mail system, and so on. They've done this in 
the belief that someone in finance, properly trained, is in a better 
position to serve as a gatekeeper to the financial applications than 
someone in IT.  Maybe, maybe not, we'll have to see.

My interest in a more sophisticated security model is to make it more 
convenient for everyone involved to push security into applications in a 
way that makes it useful. If e-mail, databases, app servers, etc. all 
consult a central security service, so user information only resides in 
one place, the administrators life becomes easier. If application coders 
can implement security by making a few api calls to verify identity and 
rights to access a specific resource, they don't each have to code their 
own security model (cringe :-). If the entire Linux community is running 
against a couple of well reviewed security models we're likely to all be 
more secure. And if applications can let users the manage the security 
of some of their own resources, like access to a schedule, project 
folder or document, they're better off, the person getting the access is 
better off and the administrator is better off.

>The richer model right now has the (good) ability of providing seperate
>permissions per object.  The problem in the UNIX world right now is that
>there is no definate standard to do this that interoperates with NFS. 
>Of course, I can't speak for AFS.  Nor can I wonder if AFS has enough
>API hooks for applications to reap the benefits of such a thing.  I
>should look sometime.
>
People have successfully dealt with the issue of distributed security in 
the past. Kerberos comes to mind (I don't recall if NFS plays with 
Kerberos or whether you need to use AFS), and the MS security model 
seems to be pretty close to what I remember VMS using to manage 
clusters. The big problem with the models I'm aware of is that they have 
real issues when they have to interact with machines that don't support 
the same model or even use the same model but work against a different 
security provider. But the hooks that are slated to show up in the 2.5 
kernel will at least let us play with mandatory access control to get 
some experience with the issues.

--rick