91–100 of 309 posts
Earlier quoted context omitted.
You should be assuming Docker is insecure until proven otherwise. Fully isolating a root user with a shared kernel is very difficult.
OpenVZ is very widely deployed and manages to do this safely.
Earlier quoted context omitted.
At the end of every iteration (of something involving this loop which I can't precisely recall now) the program checks whether it is running under debug mode (essentially makes a PTRACE call and reads its output, the OP also talks about it) If this is the case, it makes a jump to random address, so even if you are just neatly watching the program run under debug mode, you weren't going to achieve anything. Could you…
I believe it was also the part of the key.
I spent hours starring at softice & winice, and learning x86 asm
The post started very well but with the first screen shot, my mind started tingling: What the heck a security engineer is doing in a root shell? An unknown binary sent via an email is run in a root shell. There is also no mention of email source tracking. Hey you are a security engineer you know about weakness of smtp right? Even if this is a virtual machine, I would really reconsider employment of him or sit down an…
Is it really that probable that an email was sent to him from the company he is applying to and someone spoofed that to send him malware? I agree with the root point only because the company could have easily done something like `echo "I just rm -rf'ed your / because you ran me as root"` as part of the test. Why would you consider it still an issue if it was a VM he used only for this purpose?
Looking from probability perspective, yes you are right, this is a low threat vector.
Also I consider working root in a vm an issue because security 101 lesson 1 is "avoid privileged accounts as much as possible". Why not work in a unprivileged shell account and use sudo whenever needed? VMs are not bullet proof and they can leak memory, can make host machine unstable or even crash it. There are hardly any poc's out there but VM's may be exploited to switch context to host machine. Aside from these low probable threats, while working with unknown originated binaries, losing your whole work is a big probability. In this case it would not matter if you are inside a vm or not. VM's can be recovered but lost time can not be.
Real-life tests are THE best thing to send job candidates. It scales well (you don't have to spend personal hours on them) and you get real information. This applies even to sysadmins. We have a favourite: set up a VM with a slightly-broken application in a slightly-broken Apache and Tomcat, and get them to ssh in and document the process of fixing it. Even people who aren't a full bottle on Tomcat will give useful i…
It's an effective strategy from the employer's side, but what about the applicant who is asked to spend hours on some test for every job he/she applies for? Are you paying these applicants for the time they spend jumping through these hoops? And if your "technical grilling" fails to identify strong candidates, you're obviously asking the wrong questions or, at the very least, not asking the right ones.
Your objection is a fair one, but having come into the company through the process I describe I am fond of how it let me (a) show that I could actually do the stuff I claimed to be able to (b) show my thought processes and how I would deal with having received a box in this condition. So I was quite pleased to do it as a candidate. Certainly less of a waste of time than a clashing interview.
Real-life tests are THE best thing to send job candidates. It scales well (you don't have to spend personal hours on them) and you get real information. This applies even to sysadmins. We have a favourite: set up a VM with a slightly-broken application in a slightly-broken Apache and Tomcat, and get them to ssh in and document the process of fixing it. Even people who aren't a full bottle on Tomcat will give useful i…
The risk is if someone publishes a tutorial with the secrets on the web.
The point is to teach you to reason about assembly using GDB. You can pretty trivially set a breakpoint at the phoning-home routine so that you never actually lose any points; then it's just a question of thinking and reading hard enough before the deadline arrives.
Levels range from very simple string comparison, to arithmetic, to pretty weird tricks.
It was about the most memorable homework assignment I've ever done.
Real-life tests are THE best thing to send job candidates. It scales well (you don't have to spend personal hours on them) and you get real information. This applies even to sysadmins. We have a favourite: set up a VM with a slightly-broken application in a slightly-broken Apache and Tomcat, and get them to ssh in and document the process of fixing it. Even people who aren't a full bottle on Tomcat will give useful i…
It's an effective strategy from the employer's side, but what about the applicant who is asked to spend hours on some test for every job he/she applies for? Are you paying these applicants for the time they spend jumping through these hoops? And if your "technical grilling" fails to identify strong candidates, you're obviously asking the wrong questions or, at the very least, not asking the right ones.
Real-life tests are THE best thing to send job candidates. It scales well (you don't have to spend personal hours on them) and you get real information. This applies even to sysadmins. We have a favourite: set up a VM with a slightly-broken application in a slightly-broken Apache and Tomcat, and get them to ssh in and document the process of fixing it. Even people who aren't a full bottle on Tomcat will give useful i…
It's an effective strategy from the employer's side, but what about the applicant who is asked to spend hours on some test for every job he/she applies for? Are you paying these applicants for the time they spend jumping through these hoops? And if your "technical grilling" fails to identify strong candidates, you're obviously asking the wrong questions or, at the very least, not asking the right ones.
The way I do this is the real coding test is only administered to final candidates. That's a bit kinder since only a few people with a serious shot at the position end up having to commit the extra time and since we observe the whole process (and discuss) it doesn't waste tons of our time either. Whiteboard and discussion can reveal a lot but IMO there's nothing so revealing as actually watching someone work.
As an aside I would much rather be interviewed this way than at a whiteboard. At least for me there's a certain amount of my programming skill that's nonverbal and flows easier for me at a keyboard.
This is Intro to Systems homework at UChicago (the course is heavily based on CMU's equivalent.) You're given a personalized binary that asks for a series of passwords to complete each level. If you get a password wrong, it phones home to a server run by the professor and decrements your grade. The point is to teach you to reason about assembly using GDB. You can pretty trivially set a breakpoint at the phoning-home…