Sandboxing

Is it possible to write an application in "c" that can be used to start other applications and limit a process from using certain Linux APIs ( in this case I want to keep a process from being able to access the internet ) ? I've been reading "The Linux Programming Interface" by Micheal Kerrisk , but the section on "Linux Capabilities" isn't very thorough ( I think this is how such a think might be accomplished ). I'd like to write a program for "sandboxing" other programs. Any suggestions or example code would be appreciated.

Direct answer: not really feasible

Simple usable answer:
As root create the environment

groupadd no-int
useradd -g no-int testuser
mkdir /home/testuser # if dir does not exist.

#Add iptables entry:
iptables -A OUTPUT -m owner --gid-owner no-int -j DROP

For each time you want to run a new file

#To set up for a test run as root 
cp filetotest /home/testuser
chown testuser:no-int /home/testuser/filetotest
chmod 755 /home/testuser/filetotest

#to test the file in protected mode (as root)
su - testuser -c 'sg ./filetotest "parm1 parm2 ..." '

You might also consider using a restricted shell.

Thank you for the replies! I didn't know that it wasn't feasible to restrict API access to a process using the current design of the operating system ( maybe such features could be integrated into the operating systems design someday ). I've actually used the method that jim mcnamara provided so I know that this is one way to sandbox ( jgt's suggestion is new to me - I've not heard about restricted shells ). I've also heard of using Linux Namespaces , the "unshare" command to restrict programs ( maybe I could look at the source code of this application ) . I know you can use the Selinux sandbox function for this purpose too , so I guess there are a lot of options for doing this.

The reason this is not feasible is that the "API" or syscall responsible for connecting to the internat is open(). I'm not sure that a restricted shell will help with this. I hope jgt will chime in on this....

tcp sockets are treated as files by the OS. Of course the drivers are totally different. The reason iptables "works" is because it intercepts traffic at a very low level. The -j DROP will just disconnect any tcp request, based on using the -A chain specification OPEN.

I just tested rbash (restricted bash shell ):
GNU bash, version 3.2.52(1)-release (sparc-sun-solaris2.10)

I ran

wget www.google.com

in bash and in rbash.

The results were indentical. On reading the man page I found that all of the restrictions are imposed on commands and scripts, not on executable images. I still do not think that rbash can block internet access by a running program image file. It does block the bash feature of opening a socket to port 80 from the command line:

$ exec 3<>/dev/tcp/www.google.com/80
$ echo -e "GET / HTTP/1.1\n\n" >&3
$ cat <&3
# edit oops forgot to close ----------------------------------------
$ exec 3<&-
$ exec 3>&-

Ok , thank you very much for your input! I guess I'll have to use one of these methods to sandbox my applications. I wanted to write my own application , but I guess this is not currently possible .....

Well, in a sense you can. Oversimplified:

Create a network that is physically disconnected from everything. You need a DNS server ( 1.1.1.2 which gives the answers to all inquiries as 1.1.1.0, a box called internet (1.1.1.0), a box called test (1.1.1.3).

These can be virtuals on a single server. But. Treat the whole server as poison so - There cannot be any network connection out of the box. Ever.

The US National labs do this to test potential malware. You run the bad guy on test. You run your program on internet to see what traffic you get aimed for where, for example. You then indepedently check "where" against known lists like Tor access points, bad sites in general. There is a blacklist that is updated daily, I believe.

I've oversimplified this a lot. As an example, you need to be able to munge any actual ip request like 8.8.8.8 -> 1.1.1.0. The labs work with dozens of virtuals simulating various sites out in the wild.

This is also done by companies who specialize in security software. I saw a demo by folks from Sandia Labs and a security vendor a while back. Very interesting. The vendor sells the system. Duh.

Once done testing you wipe everything and restore from tape or whatever. The "whatever" cannot ever be seen by the nasty system except after a complete wipe.
The labs also reflash the bios and do some other cleansing.

Typically when setting up a user with a restricted shell, the user's profile sets the PATH variable to $HOME/bin.
The administrator then creates soft links in $HOME/bin to any programs the user is allowed to execute.

Sounds complicated. I've been reading about a function called "unshare" from "sched.h" ( I'm not allowed to add hyper text links yet ) that claims to be able to limit a programs access to the network , etc. , but I'm not sure. Anyone know about this library function?

Looks to me like you would need driver code...

unshare(2) - Linux manual page

If you persist you may yet find a way. Let us know.

I've been messing with this example from a website associated with the book I'm reading:

http://man7.org/tlpi/code/online/dist/namespaces/unshare.c.html

( Sorry if I'm not allow to sneak the link in like this )

When the code is run as root I found that the "evince" editor doesn't seem to be able to "connect out" when using a "pdf" file with hypertext links. This might work....