---------- Forwarded Message ----------
Subject: Re: Security patches 1- 3
Date: Monday 18 October 2004 23:20
From: Bodo Stroesser <bstroesser@...>
To: Jeff Dike <jdike@...>
Cc: BlaisorBlade <blaisorblade_spam@...>
Jeff Dike wrote:
> bstroesser@... said:
>>Did you get my 4th patch, too?
> No, I just went looking for it, and I don't see it.
> Resend or tell me exactly when you sent it originally so I can make sure I
> don't have it, please.
I scanned my "Sent" box and found, that I have sent the mail to you and
Paolo, but not to the list. It contained my test-tool for breakout and the
patch, inlined and as attachments. But anyway, here it is again:
Now, I found two problems in the syscall-security patches that I have
The first is the old one:
Without that patch, in SKAS mode an process that has been singlestepped,
can't be resumed with PTRACE_SYSCALL or PTRACE_CONT, but will continue to
singlestep. The new patch fixes this and also does some cleanup.
The second problem is a bit more sophisticated, even if the new patch is very
short. A part of the patch syscall-security-1 is dangerous. It is designed
to let singlestepping over syscalls work correctly on a 2.6.7-SKAS-V5 host.
Using that version as host system, syscalls with numbers greater than
NR_syscalls are not intercepted while doing PTRACE_SYSCALL. Instead, the
syscall returns immediately with result -ENOSYS. If such an syscall is
traced with PTRACE_SYSCALL, while the user wants to singlestep, the next
singlestep-trap will occur only after the next valid syscall. So I inserted
a check for the syscall number into is_syscall() to let an invalid syscall
But this is dangerous if a host uses a greater NR_syscalls than that, UML had
been compiled with. Syscalls with numbers between the two NR_syscalls values
could be started by UML processes and would than be executed on the host.
Also, I didn't realize, that if 2.4 or >= 2.6.9 is used as host, all syscalls
are intercepted, no matter what syscall-number. And this should be the
normal behaviour, since debuggers obviously want to see invalid syscalls,
And this normal behaviour is needed by UML, if someone wants to have an UML
running on a host with a lower NR_syscalls.
So, this patch removes the NR_syscalls-check from is_syscall() again, but I
would instead like to have this patch
included in the next SKAS-host patch for 2.6.7 / 2.6.8 (has to be modified
for sysemu anyway). I took the URL for one of Paolo's recent mailings.
Inserting this would guarantee for singlestepping to work correctly under
all circumstances without risk.
Paolo Giarrusso, aka Blaisorblade
Linux registered user n. 292729