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.
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.
In Section
Seekers of Perl Wisdom