Please Don't Steal My Focus

Amen!



Please Don't Steal My Focus:



'via Blog this'

Keep applications from stealing focus when opening in OS X - CNET

I am being driven crazy by applications stealing focus!!!!!!!!!



I can't believe that focus stealing is still the state of the art.  It causes bugs.  Accidental corruption and destruction of data. And it can be a security hole.





Keep applications from stealing focus when opening in OS X - CNET:



'via Blog this'

Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems

I believe that all [*] of the problems David Wheeler mentions could be solved if ALL characters in filenames were "escaped" - e.g. by placing them into some unused prefix space of your character encoding - when being processed. ALL of the characters, not just special characters.  Characters that already have such a prefix applied get two prefixes applied, etc.



Ditto for any script injection or SQL injection attacks.



Note: * I usually attempt false modesty, and say things like "all or almost all".   But this obscures the point.  ALL can be.





Fixing Unix/Linux/POSIX Filenames: Control Characters (such as Newline), Leading Dashes, and Other Problems: "Interesting alternative: Auto-convert spaces to unbreakable spaces

"



'via Blog this'

FindBin - perldoc.perl.org

FindBin - perldoc.perl.org: "If there are two modules using FindBin from different directories under the same interpreter, this won't work. Since FindBin uses a BEGIN block, it'll be executed only once, and only the first caller will get it right. This is a problem under mod_perl and other persistent Perl environments, where you shouldn't use this module. Which also means that you should avoid using FindBin in modules that you plan to put on CPAN. "

use Dir::Self instead.



(ISSUE: Dir::Self and symlinks.)

Dir::Self - search.cpan.org

Use Dir::Self to cope with the problem that FindBin should not be called more than once in a program.



FindBin for the location of the executable to find libraries relative to the executable.



use lib "$FindBin::RealBin/lib";



Dir::Self for modules that want to load other modules relative to themselves.



use lib __DIR__;



or



use lib __DIR__ . "/..";

ISSUE: is __DIR__ symlink aware - i.e. is it the equivalent of $FindBin::Bin or $FindBin::RealBin?

Compile-time vs run-time checks in Perl's Safe

I have long thought that the fundamental problem with computer security is that we don't really have a way of doing a "safe eval".



Or, conversely: lots of code really wants to evaluate code provided by a caller or user.  But doing an arbitrary "eval" is unsafe, for many well-known reasons.  So many, many programs create restricted subset languages, no matter whether interpreted or compiled, and then allow the user to specify that.  But... there are many ways in which these supposedly safe restricted subset languages can be implemented with security holes.  And they are - implemented with security holes - over and over and over again.



Heck, just figuring out how to quote text to be passed between two levels is a copious source of bugs.



I think that, in an ideal world, we might be able to code a "safe eval" once and for all.  One that is designed to test security assertions such as "cannot access filesystem".





Perl's Safe::reval  (restricted eval) is the best attempt at this that I aqm familiar with.  http://perldoc.perl.org/Safe.html



But it has problems.



One of the best known problems is that it can, or at least used to, be able to return a Perl object with a DESTRUCTOR that would execute outside the Safe compartment.  I assume that this has been fixed, since it is no longer mentioned.



Another problem, IMHO, is Safe's dependence on compile-time rather than run-time checking:

Safe - perldoc.perl.org: "Any attempt by the code in STRING to use an operator which is not permitted by the compartment will cause an error (at run-time of the main program but at compile-time for the code in STRING). "

This is a problem if you are trying to safely eval code that depends on a library that generates unsafe code - but where that unsafe code is not actually executed in the code under test.



I was hopeful that Safe made a distinction between permit/deny and trap - with trap being dome at run-time inside the compartment.  Unfortunately, not so - trap is an alias for the compile-time check deny.



Similarly eval'ing within the compartment itself...



---



So close, but not close enough. :-(





===



Of course, even if you have a properly Safe compartment, then it is up to the user, the caller, to pass the correct opcode tags.  And the opcode tags are not fine graqin enough - e.g. you might want an app to be able to access its own files but not those of another app.











'via Blog this'

Compile-time vs run-time checks in Perl's Safe

I have long thought that the fundamental problem with computer security is that we don't really have a way of doing a "safe eval".



Or, conversely: lots of code really wants to evaluate code provided by a caller or user.  But doing an arbitrary "eval" is unsafe, for many well-known reasons.  So many, many programs create restricted subset languages, no matter whether interpreted or compiled, and then allow the user to specify that.  But... there are many ways in which these supposedly safe restricted subset languages can be implemented with security holes.  And they are - implemented with security holes - over and over and over again.



Heck, just figuring out how to quote text to be passed between two levels is a copious source of bugs.



I think that, in an ideal world, we might be able to code a "safe eval" once and for all.  One that is designed to test security assertions such as "cannot access filesystem".





Perl's Safe::reval  (restricted eval) is the best attempt at this that I aqm familiar with.  http://perldoc.perl.org/Safe.html



But it has problems.



One of the best known problems is that it can, or at least used to, be able to return a Perl object with a DESTRUCTOR that would execute outside the Safe compartment.  I assume that this has been fixed, since it is no longer mentioned.



Another problem, IMHO, is Safe's dependence on compile-time rather than run-time checking:

Safe - perldoc.perl.org: "Any attempt by the code in STRING to use an operator which is not permitted by the compartment will cause an error (at run-time of the main program but at compile-time for the code in STRING). "

This is a problem if you are trying to safely eval code that depends on a library that generates unsafe code - but where that unsafe code is not actually executed in the code under test.



I was hopeful that Safe made a distinction between permit/deny and trap - with trap being dome at run-time inside the compartment.  Unfortunately, not so - trap is an alias for the compile-time check deny.



Similarly eval'ing within the compartment itself...



---



So close, but not close enough. :-(





===



Of course, even if you have a properly Safe compartment, then it is up to the user, the caller, to pass the correct opcode tags.  And the opcode tags are not fine graqin enough - e.g. you might want an app to be able to access its own files but not those of another app.











'via Blog this'