On Friday, July 27, 2012 12:27:09 PM Serge Hallyn wrote:
> Hi,
>
> I'm using the following program to allow a bunch of syscalls, then
> calling exec. According to Documentation/prctl/seccomp* I would
> expect that to work so long as NR_exec (59) is allowed (it should
> be, if I'm not mis-using libseccomp). But I'm getting -EPERM from
> execve. I do recall there were discussions of not allowing execve,
> but Documentation doesn't mention this.
>
> Should this work?
There have been discussions about disabling certain syscalls, e.g. execve(),
in certain applications, but by default the kernel doesn't disallow any
syscalls neither does libseccomp. The only things that libseccomp does by
default is set the no_new_privs prctl() flag and verify that you are not
trying to run a non-native binary. Both are tunable using the
seccomp_attr_{get,set}() functions, but it doesn't sound like that it your
problem here.
Works for me using your example on a Fedora Rawhide system:
# gcc -g -o serge serge.c -lseccomp
# ls -l /tmp
total 4
-rw------- 1 root root 51 Jul 27 14:21 tmpgiPGHp
# ./serge
tmpgiPGHp
What are you running your example on?
I noticed that your example doesn't check the return value of
seccomp_rule_add(), you might want to add that and verify that the filter is
actually being created as you intend it. The seccomp_export_pfc() function
might be helpful here too in debugging the filter.
--
paul moore
security and virtualization @ redhat
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
libseccomp-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/libseccomp-discuss
