Re: About the login shell
bobstopper@australispro.com.au writes:
> I investigated file permissions for the Hurd a couple of years ago.
> The upstream maintainer of fileutils (Michael Stone I think it was?)
> told me the Hurd shouldn't bother with the extra permission bits for
> the unauthenticated user since the problem would be much more effectively
> solved by ACLs. He further went to tell me that fileutils (back then
> in about 2000 mind you) was having ACL capabilities added to it.
>
> Consequently, assuming ACLs have been added by now (I haven't looked
> into it since) much of the work should be done and all that really
> remains is adding Hurdish support for them. And maybe patching the
> odd program which doesn't access the permissions interface in a
> manner easily translatable into ACLs.
>
> I thoroughly believe that ACLs would be a much cleaner solution for
> this problem than an extra set of permission bits. Not only would it
> incidentally solve the problem of permissions for the unauthorised
> user, it would solve any more similar problems without the further
> hacking an extra set of permission bits would require and also offer
> MUCH more flexibility for administrators and users alike to set
> permissions in precisely the way they want. Unix permission bits are
> simply incapable of fulfilling the needs of many users and ACLs would
> solve this annoying difficulty.
>
> ACLs all the way is my vote.
If this is a serious dialogue that people will be working on, we
probably have other useful work to draw from, including the
fluke/flask/flux security model (which is a capability system), the
Utah research work that became the basis of SELinux.
>From my understanding of the NSA work (aside from the contract code,
well actually Secure Computing's code was contracted as part of the
original work at utah, iirc) it is actually an implementation of this
research on a secure environment. (browse around the oskit site, the
work is there).
The NSA's work is based on ACL's _and_ Role Based Access Control,
where you have an additional level of security built in by having
assigned roles that a user can transition into and out of which map to
access controls, sort of sudo on steroids, where you don't just sudo
to root, you newrole to ROLE which has e.g. web admin access, with
only access granted to the web hierarchy, _and_ programs with the web
admin role.
If the GNU operating system wanted to make use of this work, it could
quite likely incorporate the conceptual models of role based access
control and use the port and authentication model to implement a
capability based system.
But is there a real desire to design and implement a secure
environment of this complexity?
::
I don't know, if the actual implementations could overlap as in
SELinux may be using the same parts of the inode structure to store
ACL information as translators or some other data in the Hurd.
::
--
/^\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
Reply to: