From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25785 invoked by alias); 20 Feb 2012 03:29:32 -0000 Received: (qmail 25771 invoked by uid 22791); 20 Feb 2012 03:29:31 -0000 X-SWARE-Spam-Status: No, hits=-2.8 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,TW_RG X-Spam-Check-By: sourceware.org Received: from localhost (HELO sourceware.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 20 Feb 2012 03:29:18 +0000 From: "oiaohm at gmail dot com" To: glibc-bugs@sources.redhat.com Subject: [Bug libc/13712] New: Add Type Cast to Main and Exec Calls Date: Mon, 20 Feb 2012 03:29:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: glibc X-Bugzilla-Component: libc X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: oiaohm at gmail dot com X-Bugzilla-Status: NEW X-Bugzilla-Priority: P1 X-Bugzilla-Assigned-To: drepper.fsp at gmail dot com X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact glibc-bugs-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Post: List-Help: , Sender: glibc-bugs-owner@sourceware.org X-SW-Source: 2012-02/txt/msg00221.txt.bz2 http://sourceware.org/bugzilla/show_bug.cgi?id=13712 Bug #: 13712 Summary: Add Type Cast to Main and Exec Calls Product: glibc Version: unspecified Status: NEW Severity: enhancement Priority: P1 Component: libc AssignedTo: drepper.fsp@gmail.com ReportedBy: oiaohm@gmail.com Classification: Unclassified There is a common failure solution will mean rebuilding applications. cat * simple enough right. Not really what if there is a -n file in that directory. So why does not cat not know that -n is a file. Because bash did not tell it that it was a file. There is no way for bash currently to tell cat this. So now cat presumes it a command line directive. So fails todo what user wished. Source of problem int main ( int argc, char *argv[] ) Yes the C standard. I know this will cause a lot of changes. I propose providing int securemain ( int argc, char *argv[],char *flags ) If flags=NULL pointer the call was by the old exec functions. If not null there will be 1 char per arguments giving its type. So in the case of cat * on bash. cat could receive -n as argv but since the user did not enter it F for file. Flags I would be suggesting. E environment. That is like /bin/cat ie argv 0. F for file that is anything from like * and other file search wildcards. Items known to really be filenames. U for user entered and Unknown. Like if user types cat -n * the -n is U because user entered it unless shell detects it as a directive and tags it correctly. S string N number - For program directive. Now like a python script calling exec on like cat being able to say hey that is a file stops -n file name being missed up with - program directive. S for string and N for number. Ok does not mean application does not have to check for these. But it makes it clear what these are and if the argv does not match declared type application knows it got bad feed of data somehow. So if application is expecting a F and it gets a S there is a problem type error. U is user entered its also Unknown. Bash could pick up auto completes to file and call those files not User. Same with a shell that is auto completing program directives might - it because it was a program directive the user looked up. srun could be added to work around any typing problems. What is basically srun "flagstring" application commandline so allowing user to override shell set typing. Also if you are calling from a script clearly saying where I use this var here its a file/string/number don't process it as a program directive. The basic command-line is open to like SQL injection attacks where something can pass a directive causing something the programmer never wanted to happen to happen unless something like this is implemented. Ideal is you try a srun on an application and its not a securemain executable that it fails and informs you of the case. I know this does mean that every application that needs to be secure need to be altered. I see no other way that we can add typing to the process that will work. -- at the end to say past this point don't process arguements is only useful if user types it and the application is not taking like. With cat worse is - where cat * there is a file - in the directory so when it gets to - it stops solid reading standard input and putting it back out to output. Shells need to clearly be able to tell applications that this is a list of files so files don't get used as special features because someone created a file named the same as a special feature. Also there need to be ways for scripting to type lock. Not like a script coder can be expect to know every switch of a command they are calling. They can know what switches they want and where they placed those. They can also know if something should be treated as a file name, a string or a number. This alteration allows for more solid scripting and the shell act more how the user expects so cat * if cat gets a securemain will not take - or -n filenames as a directive so print the contents of those files as user is expecting. Result is better predictability for shell users and secuirty for script writers that that call out to cat to cat something is not going to get stuck due to some evil filename. There is room for this type list to be expanded. It would be nice to see typed vars in bash but there is no point while the commands bash calls does not support type casting. The int main wrapper remains simple for platforms that don't support secure main as well. int main(int argc, char *argv[]) { int securemain ( argc,argv,NULL); } Systems that cannot do securemain basically have a small simple wrapper that disables it. Sorry I do not have the skills to write a patch to alter glibc to support this. This has to be supported from the libc first. I gave this a P1 due to the secuirty improvements and quality of command line experience improvements this opens up. -- Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.