[Bug libc/13712] New: Add Type Cast to Main and Exec Calls

["oiaohm at gmail dot com" <sourceware-bugzilla at sourceware dot org>]

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 <someoutside source var> 
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.