[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Restricted Bash - Not so restrictive (in 4.2 as well)
From: |
Sarnath K - ERS, HCLTech |
Subject: |
RE: Restricted Bash - Not so restrictive (in 4.2 as well) |
Date: |
Thu, 12 Jan 2012 15:56:19 +0530 |
Hello Jonathan,
Thanks for your inputs. I was able to created a super-restricted login.
Here are a few things that I learnt during this process:
1. "vim" has a restricted mode called "rvim (or) vim -Z". This way, I can
restrict the user from running shell commands from vim and peep into the
Filesystem
a) CAVEAT: "vim" allows the user to "read" and "write" files in the
file-system provided the user _knows_ the path (or guesses some file path)
b) So, to make it foolproof, I had to go with "nano" editor
- which supports a restricted mode that does not allow the user to edit
any other file than the one specified in the command line
c) As per your advice, I created pre-processing shell scripts which screens
the user-commands and disallows anything that contains a "/" in the arguments.
(actually, they do not allow more than 1 argument)
d) Similarly, I got pre-processing scripts for compiling and running the
test application.
I still have to block "FTP/SFTP" access. Otherwise, it will still not be
foolproof - I think.
I will look around,
Thanks for all your help!
Best Regards,
Sarnath
-----Original Message-----
From: Jonathan Nieder [mailto:jrnieder@gmail.com]
Sent: Wednesday, January 11, 2012 5:13 PM
To: Sarnath K - ERS, HCLTech
Cc: bug-bash@gnu.org; bash@packages.debian.org
Subject: Re: Restricted Bash - Not so restrictive (in 4.2 as well)
Sarnath K - ERS, HCLTech wrote:
> Apart from this, BASH Documentation says "When a command that is
> found to be a shell script is executed (see COMMAND EXECUTION
> above), rbash turns off any restrictions in the shell spawned to
> execute the script.".
>
> Does this mean that a guy with restricted shell can just write a
> shell script to do a privileged operation and get away with it?
"./my-custom-script" contains a "/".
::DISCLAIMER::
-----------------------------------------------------------------------------------------------------------------------
The contents of this e-mail and any attachment(s) are confidential and intended
for the named recipient(s) only.
It shall not attach any liability on the originator or HCL or its affiliates.
Any views or opinions presented in
this email are solely those of the author and may not necessarily reflect the
opinions of HCL or its affiliates.
Any form of reproduction, dissemination, copying, disclosure, modification,
distribution and / or publication of
this message without the prior written consent of the author of this e-mail is
strictly prohibited. If you have
received this email in error please delete it and notify the sender
immediately. Before opening any mail and
attachments please check them for viruses and defect.
-----------------------------------------------------------------------------------------------------------------------
- Restricted Bash - Not so restrictive (in 4.2 as well), Sarnath K - ERS, HCLTech, 2012/01/11
- Re: Restricted Bash - Not so restrictive (in 4.2 as well), Jonathan Nieder, 2012/01/11
- Re: Restricted Bash - Not so restrictive (in 4.2 as well), Chet Ramey, 2012/01/11
- RE: Restricted Bash - Not so restrictive (in 4.2 as well), Sarnath K - ERS, HCLTech, 2012/01/11
- Re: Restricted Bash - Not so restrictive (in 4.2 as well), Jonathan Nieder, 2012/01/11
- RE: Restricted Bash - Not so restrictive (in 4.2 as well),
Sarnath K - ERS, HCLTech <=
- Re: Restricted Bash - Not so restrictive (in 4.2 as well), Pierre Gaston, 2012/01/12
- RE: Restricted Bash - Not so restrictive (in 4.2 as well), Sarnath K - ERS, HCLTech, 2012/01/12
- Re: Restricted Bash - Not so restrictive (in 4.2 as well), Pierre Gaston, 2012/01/12
- RE: Restricted Bash - Not so restrictive (in 4.2 as well), Sarnath K - ERS, HCLTech, 2012/01/12