From - Sun Mar 28 13:22:49 1999 Path: reader1.news.rcn.net!feed1.news.rcn.net!rcn!news.maxwell.syr.edu!nntp2.dejanews.com!nnrp1.dejanews.com!not-for-mail From: Uwe Zessin Newsgroups: comp.os.vms Subject: Re: Dropping image privs Date: Fri, 26 Mar 1999 22:27:04 GMT Organization: Deja News - The Leader in Internet Discussion Lines: 188 Message-ID: <7dh1je$jg9$1@nnrp1.dejanews.com> References: <3.0.6.32.19990325123404.02ff6080@ous.edu> NNTP-Posting-Host: 194.59.248.67 X-Article-Creation-Date: Fri Mar 26 22:27:04 1999 GMT X-Http-User-Agent: Mozilla/4.51 [en] (Win95; I) X-Http-Proxy: 1.0 x11.dejanews.com:80 (Squid/1.1.22) for client 194.59.248.67 Xref: reader1.news.rcn.net comp.os.vms:225793 In article <3.0.6.32.19990325123404.02ff6080@ous.edu>, Dan Sugalski wrote: >At 12:44 PM 3/25/99 GMT, Uwe Zessin wrote: >>In article <3.0.6.32.19990324182754.02e8b8c0@ous.edu>, >> Dan Sugalski wrote: >>> At 06:21 PM 3/24/99 GMT, Uwe Zessin wrote: >>> >In article <3.0.6.32.19990323105917.02d04450@ous.edu>, >>> >Dan Sugalski wrote: [ description of Perl's taint mode removed ] >>Sounds interesting. Does it tack a 'this is dirty' to $line and any function >>that $line is given checks whether it was handed a 'dirty' object or does it >>just disable system() ? > >The variable gets tagged as tainted, and system (along with `` and open, >amongst other things) checks for it. > >>> >It's my understanding that this is just the opposite what we really want. >>> >We don't want to limit a script's ability to make use of the interpreter's >>> >functions - we want a specific script (and only that one) to work with a >>> >specific (set of) privilege(s) that the user normally does not own, right? >>> >>> Exactly. I was just curious to see if python had a paranoid mode or >>> something that made it more cautious when running setuid or with privs or >>> whatever. >> >>I'm not aware of such a thing, but I've never bothered to find out. One >>might be able to build something similar with the restricted execution >>environment I've mentioned, but it doesn't sound like a job that's finished >>before lunch ;-) > >Yeah, but can you finish it before dinner? :) I'm afraid not, but I haven't tried to find out :-) After having fixed a showstopper bug I have rather decided to work on making the next release available. Watch at http://www.decus.de/~zessin/ starting next week. With 'next week' I mean the day after 27-MAR-1999 14:00 MST at earliest, ok? (Germany goes to DST on 27-MAR at 02:00). >It might be a much smaller issue with Python code. Perl's got a number of >features that, while terribly powerful, make it easy to shoot yourself in >the foot if you're not careful. If python's a bit more restrictive in what >you can do then the danger's much less. > >Perl's open() function can create sub-processes and treat their input or >output as a file, which means you can do something like this: > > open A_HANDLE, "DIR |"; > >to have the output from a DIR command available on the A_HANDLE filehandle. >Of course, then imagine this: > > print "Enter a filename: "; > $foo = ; > chomp $foo; > open A_FILE, "$foo"; > >where the user enters "DELETE SYS$SYSDISK:[000000...]*.*;* |" as the >command. Then imagine running the script installed with privs... > >Taint mode is there to make you work to kill yourself. :) Well, there are functions like os.popen(), os.popen2() - for read/write and os.system(). But I must say that I'm always unhappy to combine user-input with os commands and execute that thing. And you can build Python commands, compile and execute them inside a script! >>> statement = 'print "Hello"' >>> exec (statement) Hello >>> Of course, the Python way to shoot yourself in your foot is to create an object, but that is wandering a bit too much off topic ... :-) [ my summary and your agreements removed ] >Part of the my plan for perl is to have the interpreter permanently drop >all image privs if the script being executed isn't on the list of approved >scripts, so noone can try to exploit it to do nasty things. That reminds me of something... Isn't the 'current privilege' mask combined with the 'image privs' so you have to turn the bits off there, too - unless one of these bits is also set in the 'process privilege' mask? Sorry, I don't remember all the details... I hope someone with a better memory - or a manual ;-) - tunes in. >[Snip of system services] > >Did you have to hand-roll all the interfaces to these routines, or did you >put together a generalized interface for all of 'em? There is no general interface, although that sounds like an interesting idea. I have picked up a small port for Python V1.2 and brought it to V1.3 a little more that 3 years ago and it has grown ever since. We're now at V1.5.1, I have tested with V1.5.2Beta2 and V1.5.2 should only be a few days away. Python provides something to parse the argument list that I can use to a certain degree, but it's not enough. One needs descriptions of the arguments (datatype, mechanism, can it be omitted) and how to deal with the data that is to be returned. Some tables already exist for routines that deal with item lists and special objects that cover VMS-related structures (FABs, RABS, XABs, ...). Once a mechanism has been worked out it's usually a matter of copying some lines of code and making some adjustments. Sometimes it might even be an overkill to try to use a general routine for all interface routines. The interface to SYS$SETEF is only 28 lines including comments and empty lines to improve readability. Here's a snipped from VMS_SYS_SETUAI.C - that's all code for the itmlst argument in the interface routine. ----- /* argument 4: itmlst */ if (!PyTuple_Check(ar_py_item_list)) { PyErr_SetString(PyExc_TypeError, "argument 4: itmlst - must be tuple of tuples"); return NULL; } else { PyObject * ar_xxx; /* SYS$SETUAI currently (V6.1) does not have any output-items */ ar_xxx = vms__itmlst_build (ITMTBL_M_ITMINP /* input-item bit */ ,0 /* ITMTBL_M_ITMOUT */ /* output-item bit */ ,&VMSDEF_GR_$UAIDEF /* VMSDEF_GR_$xxxDEF */ ,ar_py_item_list /* Python itmlst obj */ ,&ar_itemlist /* return VMS item list */ ,&ar_itm_vmsdef /* return VMSDEF back-ptr array */ ,&aw_retlenlist /* return VMS itmlst retlen array */ ); if (ar_xxx == NULL) { return NULL; /* item list build failed */ } } ----- As I have already said - I try to make available as much features of the VMS routines as possible. You can, for example, use Python's "None" object to indicate an omitted argument: >>> target_pid = vms_sys.delprc (None, "PRCNAM") However I cannot accept everything that is handed to a routine - e. g.: Python strings can be longer than 64K - I have to reject them whenever a string goes in with a descriptor / 16-bit length counter or even a 8-bit counter (Yes! I can handle ASCIC transparently - some items for $GETUAI and $SETUAI use a counted ASCII string). >>> long_string = 2000000 * '.' >>> print len (long_string) 2000000 >>> import vms_sys >>> target_pid = vms_sys.delprc (None, long_string) Traceback (innermost last): File "", line 1, in ? ValueError: argument 2: prcnam - string size limited to 65535 characters >>> For now this is hand-coded. I guess you have something similar implemented in Perl to prevent buffer overruns? --- It looks like there is a difference between using Python and Perl (or is that written 'perl'?). I follow new:comp.lang.python , but none of the Perl-related groups. When people ask how to call 'rm', 'cp' etc. from Python they are always pointed to 'os.unlink' or other builtin functions and told how to copy the file via Python I/O. I _guess_ that many people use Perl not only for tasks but very often as a filter for 'sed' replacement? So you might be right that this is not that much an issue with Python. -- Uwe Zessin -----------== Posted via Deja News, The Discussion Network ==---------- http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own