If each restriction class (i.e. CreditCard, CreditCardGatewy, PinNumber, Password) is made equivalent to a unique bit flag, you could add them together to produce a "security level bit vector". This might force more than one kind of cleaning to be done, or might restrict more kinds of usage (i.e. is allowed in a certain db field, is not allowed in a cookie, output anywhere triggers a logged alert).
This could be extended to objects, and maybe using @ISA to hold the different security classes would lend itself to describing the concatenation of restriction types.
If extended to only cleaning certain fields of an object (or keys of a hash) you could i.e. keep $o->{MothersMaidenName} while cleaning out $o->{PinNumber}.
It could scan symbol table for variables and hash keys which match certain built-in and customizable regexes, like /sec|pass|pwd|pin|salt/i, so you can enjoy reduced stress by maintaining the practice of naming sensitive variables a certain way, as in Hungarian notation (not used much in Perl though).
This could also be used to drop a security policy on top of an existing module without changing the module itself (basically tainting specific parts of some data structures it uses). Then perl -cw would tell you what it finds, i.e. "Hash key mypass used insecurely at User.pm line 100", in the case that you have a debugging statement left in. This is not of course security, but it is neat in terms of engraving that "line in the sand" a bit deeper.
Some effects I could imagine that would be useful:
Data::Dumper would show only securely cleaned strings.
Variable $cc_pin would be cleaned before destruction so it is eradicated from memory
Security policy can be implemented at prototype level
Maybe could be mixed with other prototyping modules, to allow only certain things to be sent to certain gateways (inverse of the original intent of the module).
By catching how certain variables are used, this might be used for debugging.
Being able to overlay policies over specific uses of parts of objects might be interesting for other uses than security.
Maybe it would work like this. (Pardon I am saying 'secure' this, not 'restrict' this):
use CreditCard; use Person; # a Class::DBI object use Data::Dumper; use Data::Secure qw(SecurityTypes secure secureall); my $secmgr = new Data::Secure->SecurityManager; # to alter general ope +rations $secmgr->regex = '^sec|pass|cc_/i'; # overwrite default regex $secmgr->classes = qw(CreditCard CreditCardGateway); # each has a set +of policies and cleaners associated with it. my $pincleaner = $secmgr->cleaner->new(CreditCard, qw(&cleanccpin &cle +anccnum)); # cleaners called in series $pincleaner->disable(&cleanccnum); # unload one my $perry = new Person("Perry Rhodan"); print $perry->password; # carps since "password" matches the regex secure CreditCard $perry->card; # now $perry->card ISA CreditCard my $buckaroo = secure Person->new("Buckaroo Banzai"); # $buckaroo now +secured by default policy. secure Person; # or just do this for all new instances of Person from +now on $buckaroo->addsec qw(PersonalData DenyCookies DenyTmpFolder); # Add po +licy classes, so now ISA CreditCard, PersonalData, etc. secure SecureRamen $buckaroo->noodles; # this now safe to eat secureall (CreditCard | PersonalData) Person; # secure all current and + future instances of Person. Can you do this, which also needs Credit +Card to be treated as a scalar value? my $kyle = new Person "Kyle McLaughlin"; print Data::Dumper $kyle; # this now would substitute asterisks for di +gits in $kyle->card->cc_number my CreditCardGateway $gw = $some_io_object; print $gw $kyle->card->cc_number; # okay here and db only
In reply to Re: Restricted' data, a clarification
by mattr
in thread 'Restricted' data, an additional security mechanism for Perl.
by pjf
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |