On Fri, 03 Sep 2004 22:05:03 +0200, =?UTF-8?B?S3Jpc3RpYW4gU8O4cmVuc2Vu?= said:I was not precise enough - it is not just fork, but the LSM catches every time a new process is created - so we do have some way of generic catching creation of processes, and denying so, if prohibited.
Also simple bufferoverflows in suid-root programs may be avoided. The simple way would to set the restriction "no fork", and thus if an attacker tries to fork a (root) shell, this would be denied.
All this does is stop fork(). I'm not sure, but most shellcodes I've seen
don't bother forking, they just execve() a shell....
It doesn't stop a buffer overflow that does this:You are right! ... as long as a new process is not created, this may do some damage ... but:
f1 = open("/bin/bash");
f2 = open("/tmp/bash", O_CREAT);
while ((bytes = read(f1,buffer,sizeof(buffer))) > 0)
write(f2,buffer,bytes);
fchmod(f2,4775);
close(f1); close(f2);
Papering over *that* one by restricting fchmod just means the exploit needs toNot mny suid programs would really need to be able to access the /etc and everything below... E.g. cdrecord (there were a bug a year ago or something)... it should definitely not have access to the possiblílities you mention!
append a line to /etc/passwd, or create a trojan inetd.conf or crontab entry,
Remember - just papering over the fact that most shellcodes just execve() aGood point!
shell doesn't fix the fundemental problem, which is that the attacker is able
to run code of his choosing as root.