RE: [RFC PATCH 1/1] seccomp: provide information about the previous syscall

Am 25.01.2016 4:40 vorm. schrieb "Daniel Sangorrin" <
daniel.sangorrin@toshiba.co.jp>:

There were a few important points that I didn't mention but are critical

to understand

what I was trying to do.  The focus of the patch was on protecting

"real-time

embedded IoT devices" such as a PLC (programmable logic controller)

inside a factory

assembly line .

They have a few important properties that I took into consideration:

[...]

    - Mimicry: as I mentioned in the cover letter (and Jann showed with
       his ROP attack) if the attacker is able to emulate the system

call's order

       (plus its arguments  and the address from which the call was made)
       this patch can be bypassed. However, note that this is not easy

for several

       reasons:
               + the attacker may need a long stack to mimic all the

system calls and their

                   arguments.

Note that in a ROP attack, the attacker will often set up his own stack
anyway, so I'm not sure how much of a constraint a short stack really is.

               + the stealthy attacker must make sure the real-time

application does not

                   crash, miss any of its deadlines or cause deadline

misses in other apps

                   [Note] Real-time application binaries are usually

closed source so

                    this might require quite a bit of effort.
               + randomized system calls: applications could randomly

activate dummy

                   system calls each time they are instantiated (and

adjust their BPF filter,

                   which should later be zeroed).  In this case, the

attacker (or virus)

                   would need to figure out which dummy system calls have

to

                   be mimicked and prepare a stack accordingly. This

seems challenging.

                   [Note] under a brute force attack, the application may

just raise an alarm,

                    activate a redundant node (not connected to the

network) and

                    commit digital suicide :).

About the ABI, by all means I don't want to break it. If putting the

field at

the end does not break it, as Alexei mentioned, I can change it. Also I

would

be glad to review the SECCOMP_FILTER_FLAG_TSYNC flag mentioned by Jann
in case there is any interest.

However, I'll understand the NACK if you think that the maintenance is

not worth it

as Andy mentioned; that it can be bypassed under certain conditions; or

the fact

that it focuses on a particular type of systems. I will keep reading the
messages in the kernel-hardening list and see if I find another topic to
contribute :).

You might want to look into CFI (control flow integrity) - that's probably
a much stronger mitigation than this, and it does not require kernel
support. It also works by verifying transitions, but it checks transitions
of userspace code instead of syscall transitions.