| 1. What are ibsh's main security features? |
|
the user
- can not step out of home directory
- can not access any files/resources outside the home directory
- can not execute programs, located in the home directory
- is only allowed to execute the programs, that are listed either in the global commands
file, or her group commands file.
- can not create a longer path, then 255 characters alltogether. This makes the
user space straightforward.
- can not use illegal or dangerous content in the home directory.
- the user's activities are logged to syslog (auth.log)
Go to top |
| 2. Is the user really unable to start any programs for her home directory ? |
|
Yes.
First of all, even if the home directory is in the path (usually it's not), ibsh removes it
from there, and therefore no program in homedir can be executed.
Because of this, the user can't just type ls, to start a fake ls from the home directory.
She has to type : ./ls ! But strcmp("ls", "./ls") is not 0, obviously, that is, "ls" does not
equal "./ls".. If you don't add ./ls to the allowed commands in any of the commands
file (and you better don't!!), it cant be run.
And last but not least, the x bits (execution permission) will be automatically removed
from every file in the home directory, regularly.
Go to top |
| 3. Why isn't the path of the allowed programs in the commands file, only their name ? |
|
Because ibsh reads the environmental variable PATH. Also, prior to the first release
of ibsh, i didn't want to overcomplicate things, since nobody starts ls with "/bin/ls".
So i would have had to parse the name out of the path, or add the name of the
program to the config file, which would have made the code more complicated,
and i didn't want it that time, and it hasn't changed since. Security is not
compromised, because of ibsh's PATH filtering, and paying attention to the last
detail.
Go to top |
| 4. What are the user commands files ? |
|
In the earlier version of ibsh (prior to 0.3a), only one commands file existed, listing the
commands, that are allowed to every restricted user. While certainly secure from
one end, it had one basic flaw. Why should the engineering department
(just an example) have access to the accounting software, used only by the
accountants ? The idea: allow the least only access, means, that the list of
commands must be tailored, to the personal needs of the users.
That's why the admin can now create user cmds files, and allow each user the
software she needs!
Go to top |
| 5. What about these extension lists? |
|
Ibsh doesn't allow the restricted users to have source code, elf binaries, or
other illegal/dangerous content stored in the home directories.
An employee obviously doesn't need an mp3 file in a linux shell account !
And why should she have source code files (potential exploits) be there, if she
is not a programmer ? If the user is a programmer, she ought to have bash or korn shell
instead of ibsh. If a user stores a linux binary in the home directory, which she can't
execute anyway, is also considered as a threat.
Change in v0.3a!
In this and future releases, the extension policy is changed from:
"allow all extensions, except for those listed in the xtns file" to:
"deny all extensions, except for those listed in the xtns file" ! So please, list
only the extensions, that you allow !
The admin can also create now (0.3a) user extension files. For example, a musician can store mp3's in her user space, it that legally belongs to her.
The access to the rest of the files will be automatically and without previous
warning blocked.
|