About the login shell
Moritz Schulte
I want to start this thread, because I think there is something
wrong with the GNU default login method. The question about the sense
of the login shell should maybe asked again at this time. What are
the advantages and, which is IMHO even more important, what are the
disadvantages of it?
One of the few reasons for the login shell, which come to my mind,
is: it is nice to demonstrate our feature of having zero auth handles.
Another one could be: it is convenient for the user to be able to do a
"less {README,WELCOME,...}". The most obvious consequence of the
login shell is that any random person, who might not even have an
account on the system, can get a lot of information out of the system.
It is cool to have the possibility to use the login shell - but IMHO
this login shell being the default login method on GNU has way more
important disadvantags.
For me it is simply hard to understand, why a system should be
unnecessary open and therefore forces people, who want a secure
system, to close all the wide open doors. I think, the opposite
should be the case: people, who want an especially insecure system,
should open all doors intentionally.
In times, in which GNU is just a toy system, no damage is created -
of course. But in times, in which GNU is not that for away from a
good working system anymore and even claims to be (conceptually) more
secure than Unix, this login shell does not make sense IMHO; simply
because it still wakes the impression of GNU still being a toy system.
GNU does not have to be different from Unix just to be different.
It should only be better in places where Unix was bad. And,
restricting access to a system for people not known to the system as
much as possible makes much sense in my opinion.
So, why not simply change login to loginpr in /etc/passwd in the
Debian GNU/Hurd default installation?
moritz
--
mor...@duesseldorf.ccc.de - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
--
To UNSUBSCRIBE, email to debian-hu...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listm...@lists.debian.org
James Morrison
--- Moritz Schulte <mor...@duesseldorf.ccc.de> wrote:
> Hi,
>
> So, why not simply change login to loginpr in /etc/passwd in the
> Debian GNU/Hurd default installation?
>
> moritz
Would it make sense to use debconf for this (for all the things I want to try
debconf for, I think I should try using it :)? I think that the login shell
is a good thing for first time installations. I would think that an email to
the sysadmin or a debconf question would be a better way to resolve this.
Also, as you previously mentioned there is no power in this login shell so we
aren't leaving open doors all over the place.
=====
James Morrison
University of Waterloo
Computer Science - Digital Hardware
2A co-op
http://hurd.dyndns.org
Anyone referring to this as 'Open Source' shall be eaten by a GNU
__________________________________________________
Do You Yahoo!?
HotJobs - Search Thousands of New Jobs
http://www.hotjobs.com
Moritz Schulte
> Also, as you previously mentioned there is no power in this login
> shell so we aren't leaving open doors all over the place.
Wait. As the system is right now, there's a lot of power in the login
shell from a security perspective. And now you are considering 'work
arounds', but the solution is so simple: close that door.
Maybe it would be nice to make that an debconf option. But I think,
that has quiet low priority. The FAQ would mention the same way for
configuring the login method - just with login and loginpr exchanged.
moritz
--
mor...@duesseldorf.ccc.de - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
Marcus Brinkmann
> James Morrison <rocketm...@rocketmail.com> writes:
>
> > Also, as you previously mentioned there is no power in this login
> > shell so we aren't leaving open doors all over the place.
>
> Wait. As the system is right now, there's a lot of power in the login
> shell from a security perspective. And now you are considering 'work
> arounds', but the solution is so simple: close that door.
What about making the console a login shell by default, and on remote
connections a login prompt?
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Moritz Schulte
> What about making the console a login shell by default, and on
> remote connections a login prompt?
I already found that comment in the list archive, but I still don't
get it: why do you still want to make console access so insecure?
What is the advantage? (Beside that fact that such a mechanism
wouln't be consistent).
moritz
--
mor...@duesseldorf.ccc.de - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
Marcus Brinkmann
> Marcus Brinkmann <Marcus.B...@ruhr-uni-bochum.de> writes:
>
> > What about making the console a login shell by default, and on
> > remote connections a login prompt?
>
> I already found that comment in the list archive, but I still don't
> get it: why do you still want to make console access so insecure?
> What is the advantage? (Beside that fact that such a mechanism
> wouln't be consistent).
Well, because if you need a secure console (eg, if the computer is
accessible in public), you need to take a lot of extra steps anyway to
secure the machine: You need to set a BIOS and GRUB password, for example.
So, it would make remote access more secure without inconveniencing the
local access.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Moritz Schulte
> Well, because if you need a secure console (eg, if the computer is
> accessible in public), you need to take a lot of extra steps anyway
> to secure the machine: You need to set a BIOS and GRUB password, for
> example.
Of course! Don't get me wrong, I don't want to convert the Debian
GNU/Hurd distribution into an ultra-paranoid-system with zero security
holes in the default installation since n years.
Let me describe my view like this: when I ask a company to build a
house for me, I simply expect the doors to have locks, to offer at
least some kind of protection. I know, that this protection is not
enough to have a really secure house, but there is simply no reason to
build a house without locks. Locks are the normal case, I don't have
to say "Oh, please, don't forget to install some locks!".
As far as I understand you, you as the house-building-company are
telling me "We never install locks, because the people have to secure
their houses anyway, so they can install their locks themselves.".
> So, it would make remote access more secure without inconveniencing
> the local access.
What exactly do you mean with "inconveniencing"? I mean, I use the
login shell for exactly one purpose: to type "login". When I want to
work with the system, I login, of course. Then I have my real working
environment, which is way more convenient then being the user number
-1 in the system. Therefore a login prompt is for me even more
convenient, since I don't have to type "login"...
moritz
--
mor...@duesseldorf.ccc.de - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
Roland McGrath
decisions be a matter of local administrative choice rather than imposed by
the system. For the base installation, we use the choices that we (the
Hurd developers) like for our own machines and you don't have to like those
choices.
For Debian, there are perhaps concerns such as Debian GNU/Hurd having a
default login interface consistent with Debian GNU/Linux, or certain
notions of security. I don't have an opinion about that.
Jason Dagit
login is redundant. Just like win2k where you type ctrl-alt-del (which
according to MS improves security), before you login. I think the normal
case is logining, and that is someone wants to use some other feature with
out loging in first, then they should be the one that has to do something
different. How about they hit F12, then they get what is now the default?
just a thought...I mean on my computers that don't have 'net access root
doesn't even have a password. Use security when you need it, and
conveince when you can.
Jason
Marcus Brinkmann
> Let me describe my view like this: when I ask a company to build a
> house for me, I simply expect the doors to have locks, to offer at
> least some kind of protection.
Well, I guess we could argue hours about this :) Like, I could compare your
desire to not have a login shell by default with a scenario where you ask
for a door in the house, but only holes instead windows :)
> > So, it would make remote access more secure without inconveniencing
> > the local access.
>
> What exactly do you mean with "inconveniencing"? I mean, I use the
> login shell for exactly one purpose: to type "login". When I want to
> work with the system, I login, of course. Then I have my real working
> environment, which is way more convenient then being the user number
> -1 in the system. Therefore a login prompt is for me even more
> convenient, since I don't have to type "login"...
Well, if I have a guest, I can simply tell him to use the computer, without
creating an account first.
Don't get me wrong either. The login shell is far from perfect. Much of
the policy what is accessible from it (everything world readable by default?
or by default nothing?) is undetermined. The idea is to have a reasonable
guest account with it. This means that it gives the same access to it as a
normal user account, or maybe less. We don't know.
Compare this with the other popular operating system, where you don't have a
login at all by default, you are just dropped into the one standard
desktop.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Marcus Brinkmann
> Marcus these are my feelings exactly. I think having to type login to
> login is redundant.
Well, it's easy enough to change.
> Just like win2k where you type ctrl-alt-del (which
> according to MS improves security), before you login.
It does! You should always do that, especially if you are using a shared
terminal (like one in a public computer pool). It's very important to avoid
being tricked into entering the password into a faked login program.
We should have a similar feature in the console client when it is done.
> I think the normal case is logining,
Normal for what? :) Remember that we are developing the GNU system for the
first time here, we have yet to determine what is the normal case.
> and that is someone wants to use some other feature with
> out loging in first, then they should be the one that has to do something
> different. How about they hit F12, then they get what is now the default?
Well, there is an idea about having a login prompt that allows you to drop
into a no-user login shell. This could be a good third option, or an
argument switch for the existing login prompt program.
> just a thought...I mean on my computers that don't have 'net access root
> doesn't even have a password. Use security when you need it, and
> conveince when you can.
Everybody agrees with that, I suppose :)
We should definitely disable it for remote access by default.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Robert Millan
>
> Well, if I have a guest, I can simply tell him to use the computer, without
> creating an account first.
>
> Don't get me wrong either. The login shell is far from perfect. Much of
> the policy what is accessible from it (everything world readable by default?
> or by default nothing?) is undetermined. The idea is to have a reasonable
> guest account with it. This means that it gives the same access to it as a
> normal user account, or maybe less. We don't know.
Do we have file permission bits for the unauthentificated user? I think
there wouldn't be any security problems if, say, we had files (except
/bin/login) with chmod 6440, 7550, etc. by default. Then an unauthentificated
user is, by default, completely useless and the admin can safely decide
what kind of permissions he/she wants to give out to guests.
> Compare this with the other popular operating system, where you don't have a
> login at all by default, you are just dropped into the one standard
> desktop.
such system that spawns rootshell directly is not really a good reference.. :)
--
Robert Millan
"5 years from now everyone will be running
free GNU on their 200 MIPS, 64M SPARCstation-5"
Andrew S. Tanenbaum, 30 Jan 1992
Marcus Brinkmann
> Do we have file permission bits for the unauthentificated user?
Yes. And a bit to control if it should use those or the o bits. Currently,
the default is to use the o bits, but we are not sure if we shouldn't change
that. What you described is an option we have to consider.
> > Compare this with the other popular operating system, where you don't have a
> > login at all by default, you are just dropped into the one standard
> > desktop.
>
> such system that spawns rootshell directly is not really a good reference.. :)
But it shows that for a huge number of users, security at the console
directly is not an issue. I am not sure I agree with them :)
The other problem with the login shell is that it time outs after 5 minutes
or so.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Sean Neakums
> Marcus these are my feelings exactly. I think having to type login
> to login is redundant. Just like win2k where you type ctrl-alt-del
> (which according to MS improves security), before you login.
That came from the Orange Book security guidelines, I believe. The
idea is that the SAS (secure attention sequence) is not overrideable
and thus the user can be sure that once the sequence has been entered
he is communicating with the OS and not with a Trojan. This is quite
different from typing "login" at the prompt of a program that may or
may not be the login shell.
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <snea...@zork.net> | answers a prison for oneself.
\ |
Robert Millan
> On Tue, Aug 20, 2002 at 03:15:49AM +0200, Robert Millan wrote:
> > Do we have file permission bits for the unauthentificated user?
>
> Yes. And a bit to control if it should use those or the o bits. Currently,
> the default is to use the o bits, but we are not sure if we shouldn't change
> that. What you described is an option we have to consider.
Well i think we can reach something much more secure than the "all or nothing"
unix traditional approach, too.
Let's say i want to set a public console for html browsing; on unix, users
could easily find a shell escape in the browser (for example, lynx has an
option to pipe a download through a custom application), but on the GNU system
the browser could be set as the only application the guest user can execute.
But to get it really flexible this would need a large permission table,
though, where each file has a permission set for owner, each user and each
group. I don't know if this is scalable. Maybe some rulesets can be used to
define permissions instead.
--
Robert Millan
"5 years from now everyone will be running
free GNU on their 200 MIPS, 64M SPARCstation-5"
Andrew S. Tanenbaum, 30 Jan 1992
Lionel Elie Mamane
> On Tue, Aug 20, 2002 at 03:15:22AM +0200, Marcus Brinkmann wrote:
>> On Tue, Aug 20, 2002 at 03:15:49AM +0200, Robert Millan wrote:
>>> Do we have file permission bits for the unauthentificated user?
>> Yes. And a bit to control if it should use those or the o bits.
> Well i think we can reach something much more secure than the "all or nothing"
> unix traditional approach, too.
> Let's say i want to set a public console for html browsing; on the
> GNU system the browser could be set as the only application the
> guest user can execute.
> But to get it really flexible this would need a large permission
> table, though, where each file has a permission set for owner, each
> user and each group. I don't know if this is scalable.
Isn't that (functionally) the idea behind ACL's, while they tend to be
implemented as just that: lists, and not a big table?
--
Lionel
Tom Hart
ACL's (Access Control Lists, for those who haven't heard the term
before), are, theoretically, a superior form of security for an OS,
since they allow the administrator to have more fine-grained control
over access to the system.
However, the only system I'm familiar with that uses them is Windows
NT/2K/XP. In my experience, they actually make the system less secure,
because they are much less intuitive to work with than the standard UN*X
file permissions.
I assume that the Hurd is sticking with the traditional UN*X model
because most sysadmins who are used to UNIX will find this easier to
work with. Furthermore, switching to an ACL-based model would probably
break compatibility with traditional Unices, or at the very least,
require a lot of work porting existing programs that depend on the UN*X
security model.
Of course, the flexibility of the Hurd should make it easier to build
ACLs into the GNU system at some point in the future, should the need
for them arise. (Can anyone with more experience than me comment on this?)
-- Tom Hart
hart...@brandonu.ca
Jason Dagit
On Tue, 20 Aug 2002, Sean Neakums wrote:
> That came from the Orange Book security guidelines, I believe. The
> idea is that the SAS (secure attention sequence) is not overrideable
> and thus the user can be sure that once the sequence has been entered
> he is communicating with the OS and not with a Trojan. This is quite
> different from typing "login" at the prompt of a program that may or
> may not be the login shell.
I guess my problem is that I don't believe that having the OS trap
ctrl-alt-del, and then using that to start the login is any safer. What
if it is actually a trojaned version of win98? Or what if they used one
of the many, many win2k or winNT exploits to trojan the box. It is a
programmable interrupt, you just overwrite the function pointer the OS
whats to use with your value. So to me, I think it is redundant and
annoying. But I should shut up, because from here I'm just stuborn about
it :)
Jason
Moritz Schulte
> It is a programmable interrupt, you just overwrite the function
> pointer the OS whats to use with your value.
Well, note the difference:
* login-fake-program-0 is simply a normal user program, which displays
a login screen and receives the password. No special privileges or
deep system modifications are necessary. This program will not
survive ctrl-alt-del.
* login-fake-program-1 is (as you said) a program, which has such a
power over the system that it can manipulate OS internal function
pointers.
moritz
--
mor...@duesseldorf.ccc.de - http://duesseldorf.ccc.de/~moritz/
GPG fingerprint = 3A14 3923 15BE FD57 FC06 B501 0841 2D7B 6F98 4199
Robert Millan
>
> However, the only system I'm familiar with that uses them is Windows
> NT/2K/XP. In my experience, they actually make the system less secure,
> because they are much less intuitive to work with than the standard UN*X
> file permissions.
Never heard of it, thanks.
> I assume that the Hurd is sticking with the traditional UN*X model
> because most sysadmins who are used to UNIX will find this easier to
> work with. Furthermore, switching to an ACL-based model would probably
> break compatibility with traditional Unices, or at the very least,
> require a lot of work porting existing programs that depend on the UN*X
> security model.
why? UN*X permissions can be defined using ACLs can't they? that way the
users can choose between using an ACL subset that identifies UN*X perms
or more flexible combinations.
--
Robert Millan
"5 years from now everyone will be running
free GNU on their 200 MIPS, 64M SPARCstation-5"
Andrew S. Tanenbaum, 30 Jan 1992
Marcus Brinkmann
> I guess my problem is that I don't believe that having the OS trap
> ctrl-alt-del, and then using that to start the login is any safer.
The problem is in what you believe, not the object of your belief.
Security is not only measured by practical security, but also by theoretical
models which make certain assumptions. While the operating system in
question might not be practically secure, the theoretical model is sound,
and the "magic safe login key sequence" _is_ a necessary feature of every
terminal that is shared, both for practical and theoretical security.
The other question is if the whole operating system is fake. That is an
entirely different issue, though, and has nothing to do with the feature we
were discussing. Argueing about that would avoid the question, not answer
it, and this would not be a productive form of communication.
(You secure the operating system by installing a BIOS password and a boot
loader password, and by protecting the computer physically, as well as all
privileged access to it. ALL other operations, including the fact that you
need to login at all, assume that the operating system is untampered).
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Lionel Elie Mamane
>>On Tue, Aug 20, 2002 at 05:28:12PM +0200, Robert Millan wrote:
>>> Well i think we can reach something much more secure than the "all
>>> or nothing" unix traditional approach, too.
>>> Let's say i want to set a public console for html browsing; on the
>>> GNU system the browser could be set as the only application the
>>> guest user can execute.
>>> But to get it really flexible this would need a large permission
>>> table, though, where each file has a permission set for owner,
>>> each user and each group. I don't know if this is scalable.
>> Isn't that (functionally) the idea behind ACL's, while they tend to
>> be implemented as just that: lists, and not a big table?
> ACL's (Access Control Lists, for those who haven't heard the term
> before), are, theoretically, a superior form of security for an OS,
> since they allow the administrator to have more fine-grained control
> over access to the system.
Not only the administrator: The user, too, on his files. At school,
when I'm working on a project with N other students, I appreciate that
the system permits me to ask that only these N other students (and I)
are permitted to modify the files.
> I assume that the Hurd is sticking with the traditional UN*X model
> because most sysadmins who are used to UNIX will find this easier to
> work with.
Hmm... The Hurd clearly departs from the UNIX way where it can do
better, in a way that permits it to show an unixy interface to unix
programs. I don't think this is the reason. Maybe someone that was
around back then when those decisions were made can give some insight?
> Furthermore, switching to an ACL-based model would probably break
> compatibility with traditional Unices, or at the very least, require
> a lot of work porting existing programs that depend on the UN*X
> security model.
Some systems / programs, like Samba and Solaris, already have to map
an ACL model into the Unix model, and vice-versa. As far as I know,
they don't fare that bad in doing it.
More importantly, I don't see many programs that rely on the Unix
security model. What interactions does a typical program have with the
security model:
The user requests some action (e.g. open a file). It fails, because
it is not authorised. Report it to the user. What does an ACL-based
system change there? The program doesn't care why exactly the action
is not authorised.
Programs like su, sudo, et al: They don't care either: They just want
to change permissions to the ones of another user. They do various
setuid-family calls, no direct interaction with the security model,
except that it is multi-user (it has a notion of different users).
apache serves a page only if the r bit of the o set is set. Given a
decent mapping from the ACL system to the unix system, this still
works: The ACL system surely has a notion of "permissions to any
(authenticated) user".
The programs that actually manipulate the permissions: chmod,
etc. They have to be rewritten, or new tools written. Worse, this
class includes file managers, who have to be adapted.
Programs that used to *show* permissions, like ls. As the space to
show the permissions given in an ACL system is not bounded (at least
not by a reasonable bound), I don't think ls should show the whole
ACL, only an "abstract" of it. And the mapping into Unix permission
bits is a good candidate. Obviously, you need *another* program that
shows the whole ACL.
--
Lionel
Tom Hart
>On Tue, Aug 20, 2002 at 11:28:07AM -0500, Tom Hart wrote:
>
>I assume that the Hurd is sticking with the traditional UN*X model
>because most sysadmins who are used to UNIX will find this easier to
>work with. Furthermore, switching to an ACL-based model would probably
>break compatibility with traditional Unices, or at the very least,
>require a lot of work porting existing programs that depend on the UN*X
>security model.
>
>
>
>why? UN*X permissions can be defined using ACLs can't they? that way the
>users can choose between using an ACL subset that identifies UN*X perms
>or more flexible combinations.
>
>
>
True. I may be missing the distinction between ACL's in general and how
they're implemented in NT-based systems. Especially how a user can set
file permissions in a way that prevents an administrator from reading
the user's files, unless the administrator changes the permissions.
The specific problem I'm thinking about is ACE (Access Control Entry)
inheritance, which, in my experience, is a very confusing complication
that I'm happy to avoid when using GNU systems. There is a very obscure
set of rules concerning which ACL entries take precedence between:
1. inherited versus non-inherited ACE's
2. allow versus deny ACE's
That said, if the traditional UN*X permissions model could be exposed to
the user by default (by such programs as ls and chmod), and the ugly ACL
business could be taken care of behind the scenes, that would be nice.
By providing the users with new tools and allowing them to set
permissions in a more finely-grained fashion with ACL's, an ability not
present in UN*X would be available in the GNU system. Are you suggesting
that the Hurd should at some point move to ACL's (which, I assume, would
be an in-the-future, low priority job)?
However, wouldn't it still be necessary to patch programs written for
the traditional UN*X model so that they could see the ACL's, and respect
the more fine-grained control when present?
-- Tom Hart
hart...@brandonu.ca
Tom Hart
>>ACL's (Access Control Lists, for those who haven't heard the term
>>before), are, theoretically, a superior form of security for an OS,
>>since they allow the administrator to have more fine-grained control
>>over access to the system.
>>
>>
>
>Not only the administrator: The user, too, on his files. At school,
>when I'm working on a project with N other students, I appreciate that
>the system permits me to ask that only these N other students (and I)
>are permitted to modify the files.
>
>
You're right, I stand corrected.
>
>
>>I assume that the Hurd is sticking with the traditional UN*X model
>>because most sysadmins who are used to UNIX will find this easier to
>>work with.
>>
>>
>
>Hmm... The Hurd clearly departs from the UNIX way where it can do
>better, in a way that permits it to show an unixy interface to unix
>programs. I don't think this is the reason. Maybe someone that was
>around back then when those decisions were made can give some insight?
>
>
You're right again, AFAIK. I'd also be interested in insight from
whoever has it.
>Some systems / programs, like Samba and Solaris, already have to map
>an ACL model into the Unix model, and vice-versa. As far as I know,
>they don't fare that bad in doing it.
>
>
Ah, but they were written that way to begin with. I'm sure that it is
possible to port all UN*X programs to an ACL-based model, I'm just
thinking about the work needed to do it, since there is already a lot of
porting to do.
>More importantly, I don't see many programs that rely on the Unix
>security model. What interactions does a typical program have with the
>security model:
>
> The user requests some action (e.g. open a file). It fails, because
> it is not authorised. Report it to the user. What does an ACL-based
> system change there? The program doesn't care why exactly the action
> is not authorised.
>
>
Say there's a file on a GNU/Hurd box called /home/tom/foo.bar, whose
standard UN*X permissions are wrxwrx---. Futhermore, say there's an ACE
on it that explicitly grants user Lionel read permissions. Would an
unmodified UN*X program see this ACE, and let you read my file? Or would
such programs have to be patched to see beyond the standart UN*X
permissions to the ACLs? (I'm assuming that most UN*X programs check the
file permission bits set by the filesystem, which has to do with the
implementation of ext{2,3}fs, ufs, etc., right?)
> Programs like su, sudo, et al: They don't care either: They just want
> to change permissions to the ones of another user. They do various
> setuid-family calls, no direct interaction with the security model,
> except that it is multi-user (it has a notion of different users).
>
> apache serves a page only if the r bit of the o set is set. Given a
> decent mapping from the ACL system to the unix system, this still
> works: The ACL system surely has a notion of "permissions to any
> (authenticated) user".
>
> The programs that actually manipulate the permissions: chmod,
> etc. They have to be rewritten, or new tools written. Worse, this
> class includes file managers, who have to be adapted.
>
>
Right. Such programs would use some sort of "standard UN*X" <--> ACL
translation library, I believe. Hence all the big, hard changes are made
in one place, and the programs just have to be re-written to use that
library.
> Programs that used to *show* permissions, like ls. As the space to
> show the permissions given in an ACL system is not bounded (at least
> not by a reasonable bound), I don't think ls should show the whole
> ACL, only an "abstract" of it. And the mapping into Unix permission
> bits is a good candidate. Obviously, you need *another* program that
> shows the whole ACL.
>
>
>
I agree. This abstraction could come from the translation library
mentioned above.
Robert Millan
>
> That said, if the traditional UN*X permissions model could be exposed to
> the user by default (by such programs as ls and chmod), and the ugly ACL
> business could be taken care of behind the scenes, that would be nice.
> By providing the users with new tools and allowing them to set
> permissions in a more finely-grained fashion with ACL's, an ability not
> present in UN*X would be available in the GNU system. Are you suggesting
> that the Hurd should at some point move to ACL's (which, I assume, would
> be an in-the-future, low priority job)?
Yes. That'd be very nice, but low priority indeed.
> However, wouldn't it still be necessary to patch programs written for
> the traditional UN*X model so that they could see the ACL's, and respect
> the more fine-grained control when present?
Not much trouble. programs using access() should be ok and those checking
permissions without access() are broken. specific programs that
read/modify permissions might need fixing but there are few of those. am i
missing something?
--
Robert Millan
"5 years from now everyone will be running
free GNU on their 200 MIPS, 64M SPARCstation-5"
Andrew S. Tanenbaum, 30 Jan 1992
Wolfgang Jährling
> On Tue, Aug 20, 2002 at 11:28:07AM -0500, Tom Hart wrote:
> > I assume that the Hurd is sticking with the traditional UN*X model
> > because most sysadmins who are used to UNIX will find this easier to
> > work with.
>
> Hmm... The Hurd clearly departs from the UNIX way where it can do
> better, in a way that permits it to show an unixy interface to unix
> programs. I don't think this is the reason.
We have to implement what POSIX specifies, which is the traditional Unix
model. But actually we do have an extension above it for more
fine-grained access, but applications must be aware of it: To some
extend, we have capabilities. For example when you have opened a file
in readonly-mode, the coresponding port is a capability for reading from
this file. When you pass this port to another task, you have given the
task just the permission to read from the file.
For those interested in reading more about capabilities, I can recommend
<http://www.eros-os.org/essays/capintro.html> as an introduction.
Cheers,
GNU/Wolfgang
--
Wolfgang Jährling <wolf...@pro-linux.de> \\ http://stdio.cjb.net/
Debian GNU/Hurd user && Debian GNU/Linux user \\ http://www.gnu.org/
The Hurd Hacking Guide: http://www.gnu.org/software/hurd/hacking-guide/
["Enjoy this bug as long as you can, because when we will fix it, you ]
[ will get the correct, non-functional behaviour" -- Marcus Brinkmann ]
Lionel Elie Mamane
> Lionel Elie Mamane wrote:
>> More importantly, I don't see many programs that rely on the Unix
>> security model. What interactions does a typical program have with
>> the security model:
>> The user requests some action (e.g. open a file). It fails, because
>> it is not authorised. Report it to the user. What does an ACL-based
>> system change there? The program doesn't care why exactly the
>> action is not authorised.
> Say there's a file on a GNU/Hurd box called /home/tom/foo.bar, whose
> standard UN*X permissions are wrxwrx---. Futhermore, say there's an ACE
> on it that explicitly grants user Lionel read permissions. Would an
> unmodified UN*X program see this ACE,
No,
> and let you read my file?
Yes. Programs typically just try to do something, without trying to
predict beforehand if the user is authorised to do that. They'll get
an error back from the system if, for whatever reason, the action is
not possible. I don't see why an editor would try to predict if it can
read a file. Just try, and treat the error you get, if you get one.
The only exceptions I see is:
- programs that run as one user, but provide services to another
user. These might do some "prediction work": Does the user I'm
serving has permission to do that?
But then, having the Unix permission system re-implemented in each
application is IMHO not the right way to do this. Either use
the "access" system call, or fork, setuid, and try to do the thing
in question, if it has to be performed.
example: slocate
- programs that do sanity checks on permissions of some files, like
gnupg on the secret key ring, and such.
I still think that with a decent mapping from ACL's to Unix permission
bits, these programs will perform decently, if not entirely correctly.
> I'm assuming that most UN*X programs check the file permission bits
> set by the filesystem, which has to do with the implementation of
> ext{2,3}fs, ufs, etc., right?
I'm pretty sure most programs don't: Just try to do whatever you want
to, and react appropriately if it fails.
> Such programs would use some sort of "standard UN*X" <--> ACL
> translation library, I believe.
Yes, the libc :) It is supposed to give an Unix interface, and this
includes permission bits.
Won't work for programs that touch permissions, like file managers,
though. They need to access the ACL interface directly.
--
Lionel
bobst...@australispro.com.au
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.
> ACL's (Access Control Lists, for those who haven't heard the term
> before), are, theoretically, a superior form of security for an OS,
> since they allow the administrator to have more fine-grained control
> over access to the system.
>
> However, the only system I'm familiar with that uses them is Windows
> NT/2K/XP. In my experience, they actually make the system less secure,
> because they are much less intuitive to work with than the standard UN*X
> file permissions.
>
> I assume that the Hurd is sticking with the traditional UN*X model
> because most sysadmins who are used to UNIX will find this easier to
> work with. Furthermore, switching to an ACL-based model would probably
> break compatibility with traditional Unices, or at the very least,
> require a lot of work porting existing programs that depend on the UN*X
> security model.
>
> Of course, the flexibility of the Hurd should make it easier to build
> ACLs into the GNU system at some point in the future, should the need
> for them arise. (Can anyone with more experience than me comment on this?)
--
Wolfgang Jährling
> One of the few reasons for the login shell, which come to my mind,
> is: it is nice to demonstrate our feature of having zero auth handles.
(Using the terminology from auth.defs, the login shell actually has an
auth handle, it is just associated with four empty sets of IDs in the
auth server.)
Actually, the reason you mention is not so bad: There are so many
features in the Hurd where almost nobody knows that they even exist, it
is certainly nice to use this chance to show one of them to the people.
It is so obvious that one does not want this on a "secured" system that
one certainly won't forget to change it. Therefore, if you really want
to improve security, you should maybe look somewhere else. According to
the BTS (#46709), every program on GNU/Hurd can currenty access I/O
ports directly. Before this is fixed, this system is insecure anyway.
> For me it is simply hard to understand, why a system should be
> unnecessary open
Why should it be unnecessary closed? I prefer a friendly system that
does not want to tell me "I don't trust you, go away" all the time. A
system like that would probably also become depressed because it won't
have any friends.
Cheers,
GNU/Wolfgang
--
Wolfgang Jährling <wolf...@pro-linux.de> \\ http://stdio.cjb.net/
Debian GNU/Hurd user && Debian GNU/Linux user \\ http://www.gnu.org/
The Hurd Hacking Guide: http://www.gnu.org/software/hurd/hacking-guide/
["Enjoy this bug as long as you can, because when we will fix it, you ]
[ will get the correct, non-functional behaviour" -- Marcus Brinkmann ]
David Walter
> 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
/ \
Lionel Elie Mamane
> ACL's (Access Control Lists, for those who haven't heard the term
> before), allow the administrator to have more fine-grained control
> over access to the system.
> However, the only system I'm familiar with that uses them is Windows
> NT/2K/XP.
Maybe I should describe what I know of the ACL's implemented on top of
Unix then: I had some experience with a Solaris system, and I heard
that the (since withdrawn) POSIX ACL draft was very close to this.
It is much more simple than the NT ACL's:
There are 6 types of entries:
- (user | group) owner permissions
- other users permissions
- one specific (user|group) permissions
- the mask
Directories can additionally contain so-called "default values", that
is the ACL file created in this directory will contain initially. It
is unclear to me how this interacts with the umask (maybe the mask is
set to the umask).
An user has permission to do something if ANY entry of this file's ACL
gives him permission (modulo the mask, see below). So permissions are
cumulative: when you give a group permissions, you give it to all its
users, no exception. you can't say "all the 'staff' group has write
access, but not johndoe, even if he is member of the 'staff'
group". And only this file's ACL matters. There is no concept of
inheritance.
The mask is the maximal authorisations anyone (except the user owner)
can have. So the effective authorisations applying to an user is:
(bitwise or of all ACL entries that apply to him) bitwise and (the mask)
Does this "version" of ACL's calm your fears of ACL's being
"unintuitive"?
--
Lionel
Lionel Elie Mamane
> And only this file's ACL matters. There is no concept of
> inheritance.
Err... A slight error here. As with normal Unix permission bits, you
must have "x" permission to the directory, and its parent, and it's
parent parent, etc to do anything on a file.
--
Lionel
Marcus Brinkmann
> 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.
Well, the nouser bits were a straightforward, simple addition. It was
consequent because otherwise the nouser could only ever get the same
permissions as the other user, and there would be no way to discriminate.
So, if you want to solve it by ACLs, there would be no way to have a
sensible no user without ACLs, but this is not really a desirable position.
I don't really see ACLs and the nouser bits as mutually exclusive.
Just like the normal rwx bits and ACLs are not exclusive.
> 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.
Well, it seems fileutils has ACL support and a framework for it.
> I thoroughly believe that ACLs would be a much cleaner solution for
> this problem than an extra set of permission bits.
I don't think both are addressing the same problem. You can safely assume
that everybody would need to tweak some permission bits for the no user, but
there is no reason to assume that most people would need the full weight of
ACLs.
> ACLs all the way is my vote.
In addition to what we have, certainly.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Robert Millan
>
> It is so obvious that one does not want this on a "secured" system that
> one certainly won't forget to change it. Therefore, if you really want
> to improve security, you should maybe look somewhere else. According to
> the BTS (#46709), every program on GNU/Hurd can currenty access I/O
> ports directly. Before this is fixed, this system is insecure anyway.
Does that mean i can code a hardware driver in userspace without
having the kernel concerned about it? you could have told me about this
nice "feature" last day ;)
--
Robert Millan
"5 years from now everyone will be running
free GNU on their 200 MIPS, 64M SPARCstation-5"
Andrew S. Tanenbaum, 30 Jan 1992
Marcus Brinkmann
> one certainly won't forget to change it. Therefore, if you really want
> to improve security, you should maybe look somewhere else. According to
> the BTS (#46709), every program on GNU/Hurd can currenty access I/O
> ports directly. Before this is fixed, this system is insecure anyway.
Just for the record, GNU Mach 2 has proper I/O permission control. As
usual, I didn't bother with GNU Mach 1.x, but I could switch it to provide
no I/O permissions to anyone easily :)
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Tom Hart
Ah, yes, this seems more intuitive, and more Unixy. That would be a Good
Thing. I think the non-intuitiveness of NT ACLs comes mainly from their
order-dependent nature, coupled with ACE inheritance. (And I think they
even changed the rules for which ACEs take precedence between NT4 and
Win2k.)
I STFW'd for Posix and Solaris ACLs, and there is some very servicable
information out there:
http://www.gnu.org/manual/cfengine-1.6.3/html_node/cfengine-Reference_toc.html
http://www.ietf.org/proceedings/99jul/45th-99jul-ietf-129.html
http://www.samag.com/documents/s=1151/sam0105g/0105g.htm
In particular, the GNU cfengine document describes Solaris, DFS, and NT
ACL approaches quite succinctly, and it is easy to see that NT's
approach is the most complicated of the bunch.
The one thing about NT's approach that I think is good is the presence
of Deny ACEs. If ACEs are non-inheritable, I don't think this would add
an unreasonable amount of complexity to the system. And I suspect that
there are many situations in which it would be more convenient to add a
Deny ACE to a file than to have to make a new group that excludes the
person to whom you'd like to deny access.
-- Tom Hart
hart...@brandonu.ca
Lionel Elie Mamane
> Lionel Elie Mamane wrote:
>>On Tue, Aug 20, 2002 at 11:28:07AM -0500, Tom Hart wrote:
>> Maybe I should describe what I know of the ACL's implemented on top
>> of Unix then: I had some experience with a Solaris system, and I
>> heard that the (since withdrawn) POSIX ACL draft was very close to
>> this.
>> Does this "version" of ACL's calm your fears of ACL's being
>> "unintuitive"?
> Ah, yes, this seems more intuitive, and more Unixy. That would be a Good
> Thing.
> I think the non-intuitiveness of NT ACLs comes mainly from their
> order-dependent nature, coupled with ACE inheritance.
> The one thing about NT's approach that I think is good is the
> presence of Deny ACEs.
I feel like one can't have Deny ACEs without order dependency. And
that is a bad thing, except maybe with explicit priority (each AC
entry has an explicit priority number and they are applied in that
order).
While ACE is an additional feature, I think trying to avoid creeping
featurism is a good thing, too. And I can't come up with a sensible
scenario where Deny ACEs make sense, where they really make things
better for the user, or the administrator or ... You think you can:
> And I suspect that there are many situations in which it would be
> more convenient to add a Deny ACE to a file than to have to make a
> new group that excludes the person to whom you'd like to deny
> access.
I'm curious to hear about such a scenario. With all examples that
pop-up in my head, using Deny ACEs actually would be an example of bad
administration, or rules that won't hold the passage of time. It all
revolves around "why do you want to exclude this one person"? I don't
see any reason that would apply to one person and NEVER to a new
member of the group. If you give access to group G, and user U is in
G, but you don't want to give access to group G, then either:
- G is not the right group you want to give access to. E.g. you
confuse staff members (administrators) and staff members being
formed (learning the system) (so you don't want to give them the
power to wreak havoc in the system, but the power to do small
administrations tasks). Maybe in *your* organisation, those two
groups differ by only one person, but conceptually, they are *not*
the same.
- U does not belong in G. Fix _that_.
You understand what I mean?
E.g., if you are member of the board of the Big A Corp., and you are
plotting to throw the chairman out. You don't want the chairman to be
able to read your plans, OK. But then giving access to board member,
and a Deny ACE for the chairman is not the right answer: You want that
only plotters access the plans. If a new board members is accepted,
you don't want him to automatically have access to the plans: he might
be the chairman's pawn.
In school, student Q already has stolen your work before, so you want
to deny him access to your working drafts. Again, this new kid in
school can become a friend of Q, so you won't want him to have
automatic access either. So 'all students access, except Q' isn't
quite right either.
In a different direction, it has just struck me that on a GNU/Hurd
system, I don't need to whole filesystem to support ACL's to have
fine-grained control over who access my files: Just write my own
translator :) Hmm... This would be a nice toy project to get some
experience with the system...
--
Lionel
Tom Hart
>On Wed, Aug 21, 2002 at 11:29:04AM -0500, Tom Hart wrote:
>
>
>>Lionel Elie Mamane wrote:
>>
>>
>>>On Tue, Aug 20, 2002 at 11:28:07AM -0500, Tom Hart wrote:
>>>
>>>
>>The one thing about NT's approach that I think is good is the
>>presence of Deny ACEs.
>>
>>
>
>I feel like one can't have Deny ACEs without order dependency. And
>that is a bad thing, except maybe with explicit priority (each AC
>entry has an explicit priority number and they are applied in that
>order).
>
>
I'm thinking a Deny ACE automatically overrides any Allow ACE, but with
no inheritance.
For example, say there's an "allow write to Lionel" ACE on
/home/tom/public/, but a "deny write to Lionel" ACE on /home/tom/. Since
the Deny ACE isn't inherited, there is no need for order dependency.
If there were a "Deny Read" and "Deny Execute" ACE's on /home/tom/, then
it would be as if, when you try to access /home/tom/, the "other" bits
were turned off. But this would only affect the user to which the ACE
applies.
Am I missing something here?
>While ACE is an additional feature, I think trying to avoid creeping
>featurism is a good thing, too. And I can't come up with a sensible
>scenario where Deny ACEs make sense, where they really make things
>better for the user, or the administrator or ... You think you can:
>
>
>>And I suspect that there are many situations in which it would be
>>more convenient to add a Deny ACE to a file than to have to make a
>>new group that excludes the person to whom you'd like to deny
>>access.
>>
>>
>
>I'm curious to hear about such a scenario. With all examples that
>pop-up in my head, using Deny ACEs actually would be an example of bad
>administration, or rules that won't hold the passage of time. It all
>revolves around "why do you want to exclude this one person"? I don't
>see any reason that would apply to one person and NEVER to a new
>member of the group. If you give access to group G, and user U is in
>G, but you don't want to give access to group G, then either:
>
> - G is not the right group you want to give access to. E.g. you
> confuse staff members (administrators) and staff members being
> formed (learning the system) (so you don't want to give them the
> power to wreak havoc in the system, but the power to do small
> administrations tasks). Maybe in *your* organisation, those two
> groups differ by only one person, but conceptually, they are *not*
> the same.
> - U does not belong in G. Fix _that_.
>
>You understand what I mean?
>
>
Yup.
>E.g., if you are member of the board of the Big A Corp., and you are
>plotting to throw the chairman out. You don't want the chairman to be
>able to read your plans, OK. But then giving access to board member,
>and a Deny ACE for the chairman is not the right answer: You want that
>only plotters access the plans. If a new board members is accepted,
>you don't want him to automatically have access to the plans: he might
>be the chairman's pawn.
>
>In school, student Q already has stolen your work before, so you want
>to deny him access to your working drafts. Again, this new kid in
>school can become a friend of Q, so you won't want him to have
>automatic access either. So 'all students access, except Q' isn't
>quite right either.
>
>
Ok, continuing with your example: I'm a plotter. The sysadmin gives all
employees and board members access to set permissions on their own
files, but not to create new groups. Furthermore, the sysadmin has more
important things to do than make a group for people I trust.
Hence the only way I can block the chairman is with a Deny ACE, or by
removing the "Allow access to group board" ACE, and explicitly adding
ACEs for all the plotters.
True, this leaves me open to my adversary employing an agent. But
creating a new group may not always be possible.
Also, Deny ACEs become more interesting in the context of groups, I
think, since they correspond to the set difference operation. For
example, take the groups "Students" and "Untrusted Students". Using an
Allow ACE for Students and a Deny ACE for Untrusted Students amounts to
having an Allow ACE for the group "Trusted Students" (without explicitly
creating this group).
Perhaps the system could keep track of "Virtual Groups" somehow; that
is, specify in some system file that "Trusted Students = Students -
Untrusted Students". Then the group Trusted Students could be referred
to, and would change automatically when Untrusted Students was changed.
This would renden Deny ACEs unneccessary in the Group A - Group B case.
>
>In a different direction, it has just struck me that on a GNU/Hurd
>system, I don't need to whole filesystem to support ACL's to have
>fine-grained control over who access my files: Just write my own
>translator :) Hmm... This would be a nice toy project to get some
>experience with the system...
>
>
>
Yes, that does sound like a cool project.
Lionel Elie Mamane
> Lionel Elie Mamane wrote:
>>On Wed, Aug 21, 2002 at 11:29:04AM -0500, Tom Hart wrote:
>>> The one thing about NT's approach that I think is good is the
>>> presence of Deny ACEs.
>> I feel like one can't have Deny ACEs without order dependency. And
>> that is a bad thing.
> I'm thinking a Deny ACE automatically overrides any Allow ACE, but
> with no inheritance.
> there is no need for order dependency.
> Am I missing something here?
No, if you take it that way, no order dependency.
>> I can't come up with a sensible scenario where Deny ACEs make
>> sense, where they really make things better for the user, or the
>> administrator or ... You think you can:
>>> And I suspect that there are many situations in which it would be
>>> more convenient to add a Deny ACE to a file than to have to make a
>>> new group that excludes the person to whom you'd like to deny
>>> access.
>> I'm curious to hear about such a scenario. With all examples that
>> pop-up in my head, using Deny ACEs actually would be an example of
>> bad administration, or rules that won't hold the passage of
>> time. It all revolves around "why do you want to exclude this one
>> person"? I don't see any reason that would apply to one person and
>> NEVER to a new member of the group. If you give access to group G,
>> and user U is in G, but you don't want to give access to group G,
>> then either:
>> - G is not the right group you want to give access to.
>> - U does not belong in G. Fix _that_.
>> E.g., if you are member of the board of the Big A Corp., and you
>> are plotting to throw the chairman out. You don't want the chairman
>> to be able to read your plans, OK. But then giving access to board
>> member, and a Deny ACE for the chairman is not the right answer:
>> You want that only plotters access the plans. If a new board
>> members is accepted, you don't want him to automatically have
>> access to the plans: he might be the chairman's pawn.
> Ok, continuing with your example: I'm a plotter. The sysadmin gives
> all employees and board members access to set permissions on their
> own files, but not to create new groups. Furthermore, the sysadmin
> has more important things to do than make a group for people I
> trust.
> Hence the only way I can block the chairman is with a Deny ACE, or
> by removing the "Allow access to group board" ACE, and explicitly
> adding ACEs for all the plotters.
> True, this leaves me open to my adversary employing an agent. But
> creating a new group may not always be possible.
As you say yourself, permission to board + deny to chairman leaves you
open to an attack. So why would you use that solution? Any (computer
literate) sensible person would use an explicit ACL entry for each
plotter. That scenario doesn't hold.
> Also, Deny ACEs become more interesting in the context of groups, I
> think, since they correspond to the set difference operation. For
> example, take the groups "Students" and "Untrusted Students". Using
> an Allow ACE for Students and a Deny ACE for Untrusted Students
> amounts to having an Allow ACE for the group "Trusted Students"
> (without explicitly creating this group).
Why the hell have you created "Untrusted Students" in the first place?
If you have created that group, you already think in a "Deny ACE"
way. If, at group creation time, you keep in mind that a group is used
only to give additional rights, not to remove them, you would have
created "Students" and "Trusted Students". My point is that if your
system does not support Deny ACEs, (with a good admin), you wouldn't
end up in this situation: He would have never created the group
"Untrusted Students", because it is useless.
In short:
With some brain power at group creation time, you can create the
right groups in order to never have to use set difference, only set
union. This does not increase the number of groups to create, it only
changes *which* groups you create.
More deeply, I think that with access control, you shouldn't even
think substractively. Think additively. It is always possible, and
IMHO cleaner.
> Perhaps the system could keep track of "Virtual Groups" somehow;
Again, with some care at group creation time, you don't need Virtual
Groups that are set difference of two other groups.
The only case I see is when, in an heterogenous environment, the
"first" system to be deployed was a system supporting Deny ACEs. So,
it is full of groups like "Untrusted Students". Now, you start
installing GNU/Hurd systems, and you want the users / groups database
to be shared with the other system.
But with this kind of argument, you end up adding to you system any
feature any other system has, even if it is very brain-dead.
--
Lionel
PUYDT Julien
> Why the hell have you created "Untrusted Students" in the first place?
> If you have created that group, you already think in a "Deny ACE"
> way. If, at group creation time, you keep in mind that a group is used
> only to give additional rights, not to remove them, you would have
> created "Students" and "Trusted Students". My point is that if your
> system does not support Deny ACEs, (with a good admin), you wouldn't
> end up in this situation: He would have never created the group
> "Untrusted Students", because it is useless.
I fail to see the real use of ACL vs traditional permissions in what you
describe... You're talking about root-defined groups... and they already
exist! See for example that recent article for a little discussion on
that subject:
http://www.onlamp.com/pub/a/bsd/2002/08/16/Big_Scary_Daemons.html
If users where able to create their own groups, eg friends(toto) would
be the group friends as defined by user toto, that would be new.
Just my two (euro)cents,
Snark on #hurd, #hurdfr
Michal 'hramrach' Suchanek
>
> "unintuitive"?
I think Nowell Netware had even more intuitive ACLs (but hard for the OS).
They were Supervisory,
Read, Write, Create, Erase, Modify attributes, see the File, grant Access
The rights were inherited. If you wanted people to see your directory you
grant RF to everybody on that directory. You do not need to put any ACLs on
its subdirs or files.
In addition there was inheritance mask: you could restrict which rights are
inherited at any place in the directory tree.
If the OS wanted to know what is an user allowed to do to a file, it collected
that user's name and group names. It started with the file and empty mask.
For each of the names that appears in the file's ACL and does not yet have any
associated permissions it associates any permission bits from the ACL
that do not appear in mask with that name. Then it ors current mask with
mask of the file and repeats with the file's parent, if any. Finally the rights
are ORed.
--
Michal Suchanek
hram...@centrum.cz
Jeff Bailey
> > Does this "version" of ACL's calm your fears of ACL's being
> > "unintuitive"?
> I think Nowell Netware had even more intuitive ACLs (but hard for
> the OS).
The Netware trustee system was amazing, I wish for it almost every day
that I sysadmin. There's a project on sourceforge to implement it
(google for 'trustee'). It's sad that because it's not Posix, few
people will ever implement it, though.
Tks,
Jeff Bailey
--
I reincarnated for this?
Sean Neakums
> The Netware trustee system was amazing, I wish for it almost every
> day that I sysadmin. There's a project on sourceforge to implement
> it (google for 'trustee'). It's sad that because it's not Posix,
> few people will ever implement it, though.
I seem to remember playing with an implementation of it (maybe the
same implementation to which you refer) for the Linux kernel some time
back. It was awkward to use: you have to write a text file containing
your trustee specifications and then load them into the kernel with a
utility. But it worked.
--
/ |
[|] Sean Neakums | Questions are a burden to others;
[|] <snea...@zork.net> | answers a prison for oneself.
\ |
Joshua Judson Rosen
arguing that using them is dumb]
On Wed, Aug 21, 2002 at 03:05:20PM -0500, Tom Hart responds:
> Ok, continuing with your example: I'm a plotter. The sysadmin gives all
> employees and board members access to set permissions on their own
> files, but not to create new groups.
Why is the user forbidden from creating new groups?
PS: since the topic has drifted as it has, maybe we should move/copy
discussion to bug-...@gnu.org, or one of the other lists?
--
"Trying to be happy is like trying to build a machine for which the only
specification is that it should run noiselessly."
Tom Hart
>[Lionel Elie Mamane campaigns against deny-ACEs,
> arguing that using them is dumb]
>
>On Wed, Aug 21, 2002 at 03:05:20PM -0500, Tom Hart responds:
>
>
>>Ok, continuing with your example: I'm a plotter. The sysadmin gives all
>>employees and board members access to set permissions on their own
>>files, but not to create new groups.
>>
>>
>
>Why is the user forbidden from creating new groups?
>
>
Well, a normal user account on, for example, Debian GNU/Linux, doesn't
have access to the addgroup command. Probably that is considered
"administrative", hence only administrators can add groups.
In my experience, users have very little freedom to affect the system.
On my university's network, for example, students can't even change
their backgrounds (except by using "set as wallpaper" from within a web
browser). I doubt most sysadmins would want to give users the freedom to
add system groups.
>PS: since the topic has drifted as it has, maybe we should move/copy
> discussion to bug-...@gnu.org, or one of the other lists?
>
>
>
Well, this isn't a bug, we're sort tossing around permission scheme
ideas that may be implemented in the Hurd some day, but are
low-priority. Of course, this isn't Debian-specific. We could move to
help...@gnu.org?
-- Tom Hart
hart...@brandonu.ca
Marcus Brinkmann
> Well, a normal user account on, for example, Debian GNU/Linux, doesn't
> have access to the addgroup command. Probably that is considered
> "administrative", hence only administrators can add groups.
In the Hurd, you already can split up your user and group id.
You can run your own auth server, and your own filesystem servers running on
filesystem images created in your home dir can use your own auth server.
If you also run your own password server and have your own password and
group file, you can let others make use of that to gain an id handle with
your auth server and communicate with your filesystem.
The interfaces for this are all there, you might need a few convenience
programs to really get the above set up running. In particular, there is no
easy way to use two different auth servers. But it is technically possible.
> Well, this isn't a bug
bug-hurd is also the development list.
> low-priority. Of course, this isn't Debian-specific. We could move to
> help...@gnu.org?
Also fine.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
"Niklas Höglund\" <niklas.hoglund@telia.com>"@attila.bofh.it
> On my university's network, for example, students can't even change
> their backgrounds (except by using "set as wallpaper" from within a web
> browser). I doubt most sysadmins would want to give users the freedom to
> add system groups.
On mine, we can. We're using the AFS filesystem, and any user can create
groups prefixed by his username. I (su99-nho) have a group called
su99-nho:proj.
I think this is a good way to do it. Only administrators can create any
groups, but all users have subnamespaces, that are still part of the
global namespace.
PUYDT Julien
@club-internet.fr a écrit :
> On Thu, 22 Aug 2002 12:20:38 +0000, Tom Hart wrote:
> > their backgrounds (except by using "set as wallpaper" from within a web
> > browser). I doubt most sysadmins would want to give users the freedom to
> > add system groups.
>
> groups prefixed by his username. I (su99-nho) have a group called
> su99-nho:proj.
>
> I think this is a good way to do it. Only administrators can create any
> groups, but all users have subnamespaces, that are still part of the
> global namespace.
Can you grant rights on your group, eg allow all users in one of your
groups to modify another group?
For example, if the sysadmin creates a "club" user, with a "club" group,
will it be possible to permit members of that group to decide to
add/remove someone from the group, so that a students' club can manage
itself without refering to the sysadmin again after the creation?
Snark on #hurd, #hurdfr
"Niklas Höglund\" <niklas.hoglund@telia.com>"@attila.bofh.it
> Le dim 25/08/2002 à 06:19, Niklas =?iso-8859-1?q?H=F6glund=22?=
> @club-internet.fr a écrit :
>> On mine, we can. We're using the AFS filesystem, and any user can
>> create groups prefixed by his username. I (su99-nho) have a group
>> called su99-nho:proj.
>>
>> I think this is a good way to do it. Only administrators can create
>> any groups, but all users have subnamespaces, that are still part of
>> the global namespace.
>
> Can you grant rights on your group, eg allow all users in one of your
> groups to modify another group?
>
> For example, if the sysadmin creates a "club" user, with a "club" group,
> will it be possible to permit members of that group to decide to
> add/remove someone from the group, so that a students' club can manage
> itself without refering to the sysadmin again after the creation?
Not that I know. All users can create groups prefixed by "<username>:".
I'm "su99-nho", so I can create the group "su99-nho:proj".
Users can maintain the groups themselves, so one member in the "club" can
maintain that group if it is named "user_a:club", but I don't think the
group management can be shared, and one user would "own" the group.
Basically, a group is just a shortcut so one doesn't have to specify the
entire list for every directory. (Permission management in AFS is per
directory.)
The hurd concept of cooperating auth servers (as mentioned by Marcus),
could probably be more flexible than this scheme, but it'd be nice if it
could be ensured that all users can see all other users groups, and make
their files belong to them, and so on.
Jaap Karssenberg
The following might very well be absurd, I was daydreaming.
When one allows users to create new groups within their own name space,
wouldn't a logical next step to be to let users create their own users within
their own name space (and within their own "permission space").
For example I am user "user_a" on some box and I want to share this account
with a friend of mine, but I do not want him to know my password and I want
to restrict access to some personal files. Then I should be able to create a
user "user_a:user_b" (I would be "user_a:root" myself), with his own
password, and grant him some of the permissions that I was granted by "root",
so I grant him to execute programs and access to a subdirectory of my homedir
while I restrict access to some other subdirectory and my mail account.
Of course a user could never grant permissions he doesn't have himself, only
subsets of his own rights. Also there could be somekind of "admin"
permissions, the permission to create ones own users (and/or groups) and the
permission to edit certain groups or users. This would mean a
decentralisation of the tyrannic power of "root". It would be very expandable
for systems with a large amount of users all trying to cooperate with some
other users, and all managing files for their various project groups.
It could also be easily expanded to some kind of distrubuted system.
I have no idea about the technical implementation of a permissions scheme, but
a can envision a user having his own auth server which is slave to the
systems root auth server. It seems hurdish to me to give a user as much
freedom as possible without damaging the system.
If this is really absurd, just treat me as a lunatic :)
Jaap
--
fortune says:
Ten years of rejection slips is nature's way of telling you to stop writing.
-- R. Geis
--
from: Jaap Karssenberg || Pardus [Larus]
mailto:j.g.kar...@student.utwente.nl
msn:pardus...@hotmail.com icq:89468200
http://pardus-larus.student.utwente.nl
Joachim Nilsson
> When one allows users to create new groups within their own name space,
> wouldn't a logical next step to be to let users create their own users within
> their own name space (and within their own "permission space").
Absurd and genial at the same time! Something like that would be perfect
since it would mean no more sharing of Mozilla between me and my
girlfriend. I could set up a usable environment in my home directory and
she could then get a subdirectory inside it and inherit all my base
settings - maybe even login from another client using vnc!
Regards
/Joachim
--
Joachim Nilsson - <joachim...@vmlinux.org>
+46(0)704242872 - <http://vmlinux.org/joachim/>
Marcus Brinkmann
> The following might very well be absurd, I was daydreaming.
It's not absurd at all, this (and other things) is exactly what the Hurd
author had in mind when designing the auth server.
Thanks,
Marcus
--
`Rhubarb is no Egyptian god.' GNU http://www.gnu.org mar...@gnu.org
Marcus Brinkmann The Hurd http://www.gnu.org/software/hurd/
Marcus.B...@ruhr-uni-bochum.de
http://www.marcus-brinkmann.de/
Thomas Bushnell, BSG
> Users can maintain the groups themselves, so one member in the "club" can
> maintain that group if it is named "user_a:club", but I don't think the
> group management can be shared, and one user would "own" the group.
A group can own another group, in which case any member of the owning
group can manipulate the owned group.
Michal 'hramrach' Suchanek
>
> with a friend of mine, but I do not want him to know my password and I want
> to restrict access to some personal files. Then I should be able to create a
> user "user_a:user_b" (I would be "user_a:root" myself), with his own
> password, and grant him some of the permissions that I was granted by "root",
> so I grant him to execute programs and access to a subdirectory of my homedir
> while I restrict access to some other subdirectory and my mail account.
--
Michal Suchanek
hram...@centrum.cz
David Walter
> Greetings
>
> The following might very well be absurd, I was daydreaming.
>
> When one allows users to create new groups within their own name
> space, wouldn't a logical next step to be to let users create their
> own users within their own name space (and within their own
> "permission space").
>
> For example I am user "user_a" on some box and I want to share this
> account with a friend of mine, but I do not want him to know my
> password and I want to restrict access to some personal files. Then
> I should be able to create a user "user_a:user_b" (I would be
> "user_a:root" myself), with his own password, and grant him some of
> the permissions that I was granted by "root", so I grant him to
> execute programs and access to a subdirectory of my homedir while I
> restrict access to some other subdirectory and my mail account.
I've been considering something like this. You could do this, in
another way, if we assume that user_b has an account then we can set
up file sharing using a translator (next post will outline the idea
I'm going to be working on) where you can grant on a per
{file,directory} basis constrained access.
Further, you could use an authentication mechanism like the users pgp
public key or other, as a partial authentication, beyond a login
mechanism.
> Of course a user could never grant permissions he doesn't have
> himself, only subsets of his own rights. Also there could be
> somekind of "admin" permissions, the permission to create ones own
> users (and/or groups) and the permission to edit certain groups or
> users. This would mean a decentralisation of the tyrannic power of
> "root". It would be very expandable for systems with a large amount
> of users all trying to cooperate with some other users, and all
> managing files for their various project groups. It could also be
> easily expanded to some kind of distrubuted system.
> I have no idea about the technical implementation of a permissions
> scheme, but a can envision a user having his own auth server which
> is slave to the systems root auth server. It seems hurdish to me to
> give a user as much freedom as possible without damaging the system.
I'm not sure, but I'm thinking that if an individual has permission to
connect a new translator to the filesystem, it would be difficult to
deny them the creation of their own translator which would allow them
to do this whether the admin wanted them to or not?
But that is perhaps the inverse of your proposal.
--
/^\
\ / ASCII RIBBON CAMPAIGN
X AGAINST HTML MAIL
/ \
Anders Jackson
Jaap Karssenberg <j.g.kar...@student.utwente.nl> writes:
> Greetings
>
> The following might very well be absurd, I was daydreaming.
>
> When one allows users to create new groups within their own name space,
> wouldn't a logical next step to be to let users create their own users within
> their own name space (and within their own "permission space").
[...]
Wasn't this implemented like this on Digitals large machines (PDP-10
running PDP-20)?
/Jackson