Features Download
From: Paul Moore <paul <at> paul-moore.com>
Subject: Re: RFC: seccomp LSM
Newsgroups: gmane.linux.kernel.lsm
Date: Monday 25th March 2013 19:33:21 UTC (over 4 years ago)
On Friday, March 22, 2013 03:44:23 PM Michael Cassaniti wrote:
> I haven't given up though. I looked through
> include/uapi/asm-generic/unistd.h and found that there are roughly 273
> defined system calls ...

It is important to note that syscalls are architecture dependent, e.g. the 
tuxcall() syscall doesn't exist on x86 or ARM.  Taking into consideration
x86_64, x32, and ARM I count ~390 unique syscalls (I may be missing one or 

> I have grouped these system calls into 32 groups,
> and selected 15 system calls to stand out individually. Some system
> calls are also allowed by default (e.g: uname). I have also split some
> of those groups of system calls into two sub-groups; those that don't
> have any side effects when called and those that do.
> Please note that side effects here is quite loose. An example would be
> the read call on a file handle. While it does have some effect on system
> state, within context it doesn't have a side effect.

I think a better definition of "side effects" is needed, especially how
effects" differ from general system state.

> ... I'm no kernel developer ...

Be careful, you've already submitted some kernel patches; keep on this
and you might just wake up one morning and find yourself a kernel developer

> and my choice of groups is certainly open to
> debate. In fact I would rather someone else group system calls into
> logical groups for filtering.

Kernel development is no different from anything else in life, if you want
done be prepared to do it yourself.  Make the grouping (as you've done),
let others suggest something else if they don't like it.

Also, who is going to maintain this long term?  If you aren't going to
around to deal with the bugs and the inevitable addition of new syscalls 
(don't expect others to group the new ones - they will forget) then you are

going to have a hard time getting your code merged.

> My main aim is to get a system
> administrator able to create a basic seccomp filter that says something
> like "this application can do file read/write, but no extended attribute
> operations, I/O operations, etc". If the seccomp filter needs to be more
> fine grained than this, a proper seccomp filter should be used.

I think this is a good place to start - the interface the sysadmin will use
configure this functionality.  More on this below ...

> === Groups ===
> Note that some of these groups specify sub-groups ...

No comment on the groups at this time.

> === Inherit bit explanation ===
> I know it has come up before, but I want to see inheritance of parent
> seccomp filters be optional.

You might want to suggest this separately.  I understand that without this 
functionality the functionality you are proposing is not as attractive, but

this really sounds like two separate "things" to me.

> === Use case ===
> I know someone will ask the use case question and happily point out
> SELinux, AppArmor, etc that might fit better. While that is all nice, it
> is the complexity that is the reason it is skipped over.

I don't think anyone on this list is going to argue that seccomp is a 
replacement for SELinux, Smack, AppArmor, and/or TOMOYO.  With the
of Yama, which is a very special case LSM, the LSMs are designed to control

the interaction of the different moving parts of a working Linux system 
whereas seccomp is designed to limit the kernel functionality exposed to a 
process in hopes of reducing the kernel's attack surface.

These are two very different things and one of the reasons I think your 
subject line of "seccomp LSM" is a bit interesting/peculiar.

> === Applying the filter to the binary ===
> Originally I thought it might be worth while to add this filter as a
> bitmap security extended attribute associated with the binary.
> Unfortunately this doesn't scale so well (5000 binaries, 5000 individual
> filters with duplications). Instead I'm suggesting a text label in the
> security extended attribute, and associating a seccomp filter specified
> within a policy to this label. This should be similar to how Smack
> associates a text label to a subject/object, and then determines the
> actions a subject can perform on an object.

How does one define and manage the labels?  Can you combine seccomp labels
a xattr or do you need to create a new unique seccomp label that is a union
the two?

Also, how do you handle non-native architectures, e.g. x86 on x86_64?

> Thoughts/comments on long winded RFC?

Once again, I hate to be the bad guy but I'm still not entirely convinced
this is something sysadmins will want to administer/maintain over the life
their systems but I could be wrong.  At the very least it is a definite 
improvement over your last design, the usability improvements are a step in

the right direction.

paul moore

To unsubscribe from this list: send the line "unsubscribe
linux-security-module" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
CD: 13ms