Hi! ----
A few days ago I filed http://bugs.opensolaris.org/view_bug.do?bug_id=6596519 ("RFE: Add pam_shell.so.1 module") and today found the comments (see quoted text below) in the bug... since there is no "reply"-button at http://bugs.opensolaris.org/ I'll try to answer the comments here: > I think the concept is great. Similarly there should be the ability to > write the > modules in perl, python etc. Erm, technically the idea was _not_ to execute an external interpreter (e.g. #!/bin/perl), the idea was to run an interpreter "inline" within the current process and therefore avoid the problem if shuffeling data around and allow some things like _setting_ PAM attributes from within the script (AFAIK this can't be done (easily) when an external process is used, right ?). > However there are possibliy HUGE security implications here. Running > shell script inside a login program that is running with all privileges > (usually since it is a requirement of PAM) scares me quite a bit. Why ? Shell script can be written in a secure way (a while ago David Korn commented on the issue) and the use of a scripting language avoids the usual "attack vector" of string/buffer overflows which may happen in native C applications (assuming the shell interpreter code itself has no related flaws). Additionally I was thinking about some things further things to improve security in the executed shell script: 1. We set IFS='' before starting the shell script, killing any attempts to inject shell code that way (this matches David Korn's recommendation for setuid/setgid shell scripts) 2. Pass all PAM paramters in a compound variable (for example "pam.") and don't use the normal shell argument list 3. Subshells won't have access to PAM data/functions (which is more or less "natural" shell behaviour since most shells (excluding ksh93) run subshells in seperate processes) 4. Return values are passed either via the proposed libpam API mapping to ksh93 builtin commands or the a compound variable, e.g. stdout/stderr is not parsed for status information (therefore avoiding any parser bugs or similar attack vectors) 5. Think about passing the scripts as a file descriptor and not via name (see intexec module's behaviour for setid scripts, AFAIK it may not be needed but I am not sure right now (it's 1:32h here)) An additional idea may be to run "critical things" (e.g. parsing of config files etc.) like this: # start critical section -- snip -- # do something ( export PATH=/this/leads/to/$RANDOM/nowhere set -o restricted # do some stuff ) -- snip -- # do something The idea is to use the ksh93 feature that the restricted shell mode can be dynamically enabled for subshells, e.g. after "set -o restriced" the shell will only execute commands which are accessible via ${PATH} (including builtins if they are bound to a path etc.) - see ksh93(1), section "restrice shell mode". > I think the best way forward here is to get a prototype up and running > and do a detailed security audit to make sure that admins writting shell > script pam modules can't trivially destroy security. How is the audit done ? > Thats not to say > you can't do it today using a PAM module in C but it feels to me like > shell scripts have so much more potential to go wrong. Do you have any examples for stuff which may go wrong ? > I'm going to mark this incomplete for now because much more detail is > needed on exactly how this will work and what restrictions there should > be on where the shell scripts live, how the PAM module calls them, how > we keep this secure etc. Ok... ---- Bye, Roland -- __ . . __ (o.\ \/ /.o) roland.mainz at nrubsig.org \__\/\/__/ MPEG specialist, C&&JAVA&&Sun&&Unix programmer /O /==\ O\ TEL +49 641 7950090 (;O/ \/ \O;)
