From: <jam...@te...> - 2002-06-25 12:46:51
|
>> will be created. When you do step 4, remove the module, the acl hangs >> around (i.e. it does not get deleted). I am not sure if this could be >> exploited or even lends itself to a writer of a module shooting themselves >> in the foot and allowing what was not intended to be allowed. Even >> still I don't think its the right thing to do. Is this seen as >> a problem by any others? > > That is actually a feature, so that if you give the module back to the > user in future he will have the same access control settings as before. I kind of figured that may be the reason its left around. My main concern with it being left around is a module being written that uses another modules ACL for something becuase it is going to use a foreign function from that module. What should occur (at least as I understand it the webmin code) is: 1) Make sure the user can even use the foreign module at all; if not abort (or don't show the link (-:). 2) Then make sure the user can do the particular foreign funciton. What I am afraid of is code that is written that neglects to do the first check. What I think could avoid this from occuring and still keep the feature around (I agree it is a nice feature; I am just your security paranoid concience talking to you (-;) is that you rename the acl when that module is removed from the users list of modules. For instance, say its user test, and the fdisk module is being removed, then the acl file: fdisk/test.acl could be renamed to: fdisk/_old_test.acl or prepend a dot or whatever seems nice. If the module gets added back then it would look for the users old acl file and rename it appropriately. Just a thought...james |
From: <jam...@te...> - 2002-06-26 13:13:22
|
> That wouldn't really make any difference, unless there was another module > also in the /fdisk/ directory, which should never happen. Modules don't look > at each other's .acl files at the moment, not even for foreign function calls > (which are always assumed to be trusted). Well, what you are really saying is that the webmin infrastructure does not support this in a portable from release to release way. To which I would submit that if I did do a foreign function call, and the thing that I was calling had a ACL attached to it, I would indeed verify the modules ACL's (which is trivial) to see if the current user should be doing that. >ACL checking is done at the .cgi program > level, not in the underlying libraries, Understood from the begining, though that is not a bad idea (-; Really, what I am saying is that in a module's .cgi program it decides to use a foreign function which the .cgi program in the foreign module would make some ACL check against before calling this foreign-but-not-foreign-to-itself function then I want to make the same check myself in my module (hope that made sense). > so even if you don't have access to the /mount > module you can still see information about mounted filesystems in the /fdisk module. > Anyway, I am totally sure that there is no security risk in leaving .acl files around. A loose security framework makes it easy for someone who does not fully understand the framework to oops. Not to quote a rabbi, but "make fences". > If anything, removing them would be a security risk because if you deleted a module and > then re-installed it, all users with access to it would get fully privileges if the .acl > files were deleted. When you reinstalled the module, no one should have access, because when you removed the module that module should have been removed from all users list of accessible modules. Which I assumed was what happened (trying to hope for the best; but then again one musn't assume (-;). Cheers...james |
From: Jamie C. <jca...@we...> - 2002-06-26 14:16:02
|
jam...@te... wrote: > >>That wouldn't really make any difference, unless there was another module >>also in the /fdisk/ directory, which should never happen. Modules don't >> > look > >>at each other's .acl files at the moment, not even for foreign function >> > calls > >>(which are always assumed to be trusted). >> > > Well, what you are really saying is that the webmin infrastructure does not > support > this in a portable from release to release way. To which I would submit > that if I did > do a foreign function call, and the thing that I was calling had a ACL > attached to it, > I would indeed verify the modules ACL's (which is trivial) to see if the > current user > should be doing that. That doesn't happen, because often one module will make limited use of another module to carry out certain tasks. For example, a user might have access to the Change Passwords module but not to Users and Groups. However, the password module makes foreign calls to users and groups, and edits unix users that the user would not be able to edit manually. If ACL checking was done at the function level, this wouldn't be possible .. >>ACL checking is done at the .cgi program >>level, not in the underlying libraries, >> > > Understood from the begining, though that is not a bad idea (-; > > Really, what I am saying is that in a module's .cgi program it decides to > use > a foreign function which the .cgi program in the foreign module would make > some > ACL check against before calling this foreign-but-not-foreign-to-itself > function > then I want to make the same check myself in my module (hope that made > sense). That makes sense, and I can see situations in which a module would want to do that. But none of the core modules have a need to at the moment .. >>so even if you don't have access to the /mount >>module you can still see information about mounted filesystems in the >> > /fdisk module. > > >>Anyway, I am totally sure that there is no security risk in leaving .acl >> > files around. > A loose security framework makes it easy for someone who does not fully > understand the > framework to oops. Not to quote a rabbi, but "make fences". > > >>If anything, removing them would be a security risk because if you >> > deleted a module and > >>then re-installed it, all users with access to it would get fully >> > privileges if the .acl > >>files were deleted. >> > > When you reinstalled the module, no one should have access, because when > you removed the > module that module should have been removed from all users list of > accessible modules. > Which I assumed was what happened (trying to hope for the best; but then > again one musn't > assume (-;). That doesn't happen at the moment - if you remove a module and then re-install it, the same people will still have access, with the same permissions. Maybe I should add an option when removing a module to remove it from all users and to delete all .acl files .. - Jamie |
From: Jamie C. <jca...@we...> - 2002-06-26 01:45:59
|
jam...@te... wrote: >>>will be created. When you do step 4, remove the module, the acl hangs >>>around (i.e. it does not get deleted). I am not sure if this could be >>>exploited or even lends itself to a writer of a module shooting >>> > themselves > >>>in the foot and allowing what was not intended to be allowed. Even >>>still I don't think its the right thing to do. Is this seen as >>>a problem by any others? >>> >>That is actually a feature, so that if you give the module back to the >>user in future he will have the same access control settings as before. >> > > I kind of figured that may be the reason its left around. My main concern > with it being left around is a module > being written that uses another modules ACL for something becuase it is > going to use a foreign function from that > module. What should occur (at least as I understand it the webmin code) > is: > > 1) Make sure the user can even use the foreign module at all; if not > abort (or don't show the link (-:). > 2) Then make sure the user can do the particular foreign funciton. > > What I am afraid of is code that is written that neglects to do the first > check. What I think could avoid this from occuring > and still keep the feature around (I agree it is a nice feature; I am just > your security paranoid concience talking to you (-;) > is that you rename the acl when that module is removed from the users list > of modules. For instance, say its user test, > and the fdisk module is being removed, then the acl file: > > fdisk/test.acl > > could be renamed to: > > fdisk/_old_test.acl > > or prepend a dot or whatever seems nice. If the module gets added back > then it would look for the users old > acl file and rename it appropriately. That wouldn't really make any difference, unless there was another module also in the /fdisk/ directory, which should never happen. Modules don't look at each other's .acl files at the moment, not even for foreign function calls (which are always assumed to be trusted). ACL checking is done at the .cgi program level, not in the underlying libraries, so even if you don't have access to the /mount module you can still see information about mounted filesystems in the /fdisk module. Anyway, I am totally sure that there is no security risk in leaving .acl files around. If anything, removing them would be a security risk because if you deleted a module and then re-installed it, all users with access to it would get fully privileges if the .acl files were deleted. - Jamie |