Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change

Re^4: Authentication with /etc/shadow

by fluffyvoidwarrior (Monk)
on Feb 27, 2011 at 11:22 UTC ( #890399=note: print w/replies, xml ) Need Help??

in reply to Re^3: Authentication with /etc/shadow
in thread Authentication with /etc/shadow

Thanks. That's a lot to think about.

One immediate answer to part of your post is that physically stealing something - hard drive or system unit - would be immediately noticed. Copying software would be much harder to prevent in this environment.

Yes, chunks of it need rewriting as compiled binaries but the client moved the goalposts and wants it running next week - no time

I have absolutely no objection to using PAM for this but it looked like a lot of overhead so I thought of a quick password hash comparison.

Protecting user login security is almost irrelevant since unauthorised login is not possible without physical attack and is almost meaningless in this context anyway since many varied people will use this system on the premises with no personal login at all. I am not trying to safeguard that type of security. I am not trying to authenticate user logins, I am trying to detect if my system is running off the premises and prevent or delay it's use.

One interesting point you made touches exactly on one of my major concerns - "a risk that an enterprising hacker can intentionally create and take advantage of time gaps between the launching of the Perl interpreter and the loading of your script to change the effective user id or wreck other havoc." In an attempt to counter such an approach my program checks it's effective user id on each pass. My assumption was that to crack a perlapp, this would be a likely route. My hope was that for an attacker to take this route the perlapp would have to be run and so would have a chance to fork and render itself useless.

I am looking for roadblocks and delays in an unusual security context.

And, sorry, I am aware that there are inconsistencies in what I am telling you. A bit like visiting the doctor and lying about your symptoms. However, your critical input is helpful nevertheless.

Replies are listed 'Best First'.
Re^5: Authentication with /etc/shadow
by ELISHEVA (Prior) on Feb 27, 2011 at 12:35 UTC

    I feel like I'm shooting in the dark here, but ...

    If the particular computer you are running on is an issue, why not check the BIOS serial number and manufacturer id and have your script run only if it is on the correct machine? If buying time is also concern you could generate fake output and even try to silently send an email to supervisors if it running on the wrong machine complete with the CPU info of the interloper so that follow-up actions or even prosecution would be easier. No point in letting the attacker know his/her attack even failed.

    Also do you have in place some sort of digital signing? Can you prevent scripts running if their checksum or digital signature changes? If someone can copy your scripts, might they also not be able to edit them to remove any security checks and delaying tactics you try to insert? If that is the case your EUID check solution (or for that matter a CPU check) isn't a solution at all. If you encapsulate your checks in function calls, Perl makes it dirt easy to redefine a function call. If you hard code your checks in several places in your script, you will be dealing with a maintenance problem. Furthermore, assuming your envisioned attacker is more than your average script kiddie, I'd suspect that he or she would be quite adept at using sed, vi, emacs/emacs, perl or any number of tools to do regex based global search and replace.

      Yes, checksum is a good idea, I'd already decided on hardware checks.

      Also, checking code is kept in the main loop - no function calls - for the reason you suggest and is encountered prior to any sensitive functionality. (also duplicated within the most sensitive function block in a .pm file) If any checks fail the program goes into a blind loop and never encounters the sensitive instructions

      I suppose I am, in the immediate instance, trying to rely on and beef up the limited security value of perlapp executables in order to buy myself some time to develop a better solution. My hope is that a perlapp could not be easily decrypted cold and that it would probably be run to be cracked. When it runs I may be able to get lucky.

      I know it's a less than perfect situation but it's all I've got now, this minute. I can only do the best I can with the tools I've got in the situation I find myself.

      Perl is an unbeatable problem solving and prototyping system. It has solved problems here that I doubt could have been as well done with other languages. The client is well pleased, so pleased they are insisting on going live NOW, with a Perl only setup. They have "Confidence in my ability to safeguard their interests" .... They are non-technical and have more confidence than I do...

        Ah.. the old "the prototype works so well, why do we need the real system?" That surely isn't an easy situation. No one wants to spend more money than they have to.

        Would they be open to a conversation about the different goals of prototyping and why prototyping often looks like a complete system when it isn't? One analogy that you might want to play around with: a prototype is like the costumes and scenery in a period drama. The costumes often look authentic and they successfully support the story. You can dance and sing and act in them.

        However, those costumes are rarely wearable on the street. They would never make it through the washing machine. Seams are basted or pinned rather than stitched. Materials that look like silk are used instead of real silk. Cloth with the durability of gauze is used instead of sturdy broadcloth. Buttons and zippers are fake - up close the clothes use cheap snaps and clasps that easily tear off.

        A prototype is like the period costumes. They are good enough to give a realistic feel for what the system does and to ferret out any logical inconsistencies in the design specs. However, they aren't designed for operational strength because that would take time and attention from the more important job of making sure developer and client truly understand each other. If you want to wear stage costumes on the street you have to turn those pinned seams into stitches. In the same way if you want long term durability and security, you sometimes have to rewrite parts of the prototype in a more robust medium.

        Good luck!

Log In?

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://890399]
and all is quiet...

How do I use this? | Other CB clients
Other Users?
Others romping around the Monastery: (3)
As of 2018-04-23 18:10 GMT
Find Nodes?
    Voting Booth?