# pppoe, jails, firewalls and me



## deadbeef (Nov 26, 2019)

Hey Community,
I want to try something but need some advice before I start.
If I open a pppoe connection on a machine which has some jails instantiated,
could these (maybe compromised) jails do something nasty with that tun device? 

In my understanding the kernel creates the pppoe device which is shared by all jails on the host. 
Even if I create the pppoe interface inside a jail, it wouldn't make any difference, am I right?
Could this lead to more trouble than security?

And what about firewalling inside a jail?

Any suggestions or Ideas? Im thankful for any shared knowledge.


----------



## SirDice (Nov 26, 2019)

deadbeef said:


> If I open a pppoe connection on a machine which has some jails instantiated,
> could these (maybe compromised) jails do something nasty with that tun device?


Not with the device itself but they could use the connection and reach out to something on the other end of the tunnel. 



deadbeef said:


> In my understanding the kernel creates the pppoe device which is shared by all jails on the host.


It's not shared by the jails, it's the host that has the access and jails are connected to the host too. The host takes care of routing and such, so your jails could potentially access the same network(s). 



deadbeef said:


> And what about firewalling inside a jail?


Not possible with 'standard' jails, a 'regular' jail can't control its network interface. With a VNET jail, the jail has it's own interface it can control and you can run a firewall on that. But keep in mind, if your jail is compromised what's stopping them from disabling or modifying the local firewall?


----------



## deadbeef (Nov 26, 2019)

SirDice said:


> Not with the device itself but they could use the connection and reach out to something on the other end of the tunnel.


Is there any chance to hide other interfaces from a jail except the assigned ones in the config?
If not, what's the purpose behind a jail?



SirDice said:


> It's not shared by the jails, it's the host that has the access and jails are connected to the host too. The host takes care of routing and such, so your jails could potentially access the same network(s).


So a jail could also gain access to the interfaces of the other jails too?

Then i could setup a dns or a web server directly on the host system. if one of them gets compromised, its like the whole system is gone because I could access all physically attached networks anyway. Am I misunderstanding something?


----------



## SirDice (Nov 27, 2019)

deadbeef said:


> Is there any chance to hide other interfaces from a jail except the assigned ones in the config?


The device is hidden by default due to devfs.rules(5). But this doesn't prevent basic TCP/IP routing on the host itself.


deadbeef said:


> If not, what's the purpose behind a jail?


Separation of processes, nothing more, nothing less.



deadbeef said:


> So a jail could also gain access to the interfaces of the other jails too?


You're too focused on the devices themselves. Those are mostly irrelevant, it's plain and simple TCP/IP. 



deadbeef said:


> if one of them gets compromised, its like the whole system is gone because I could access all physically attached networks anyway.


No and yes. The whole system isn't gone but a compromised jail can attack, over the network, other hosts or jails.


----------



## deadbeef (Nov 27, 2019)

SirDice said:


> No and yes. The whole system isn't gone but a compromised jail can attack, over the network, other hosts or jails.


ONLY over the network? (assuming there is no major bug in the jail software causing fatal errors)
If build up a firewall for the entire network and then for the jails itself, this risk could be minimised?



SirDice said:


> Separation of processes, nothing more, nothing less.


Thank you for your thoughts till here. Funny how that sentence change the meaning of jails for me.


----------



## SirDice (Nov 27, 2019)

deadbeef said:


> ONLY over the network? (assuming there is no major bug in the jail software causing fatal errors)


Barring any bugs, yes. There are also ways to significantly decrease the jail's security by allowing mounts, SYSV IPC and/or shared memory, things like that, that's why it's all disabled by default. 


deadbeef said:


> If build up a firewall for the entire network and then for the jails itself, this risk could be minimized?


Treat a jail like a separate machine on your network and work from there. Are your other (physical) machines capable of connecting to other hosts? You're going to need some connectivity or else there would be no reason to network them in the first place. Firewalls are nice of course but you're going to need to poke holes in them, those holes are needed for your applications but can just as easily be used as paths for malicious intent. 

This reminds me of an old April fools RFC, the 'evil' bit security flag in IP packets: https://tools.ietf.org/html/rfc3514


----------



## deadbeef (Nov 27, 2019)

SirDice said:


> There are also ways to significantly decrease the jail's security by allowing mounts, SYSV IPC and/or shared memory, things like that, that's why it's all disabled by default.


You mean mounting a device from the host inside the jails directory tree?
would it make any difference if I mount a nas drive from the jail itself?
Or do you mean mounting at all?



SirDice said:


> This reminds me of an old April fools RFC, the 'evil' bit security flag in IP packets: https://tools.ietf.org/html/rfc3514


Well.. it would have made our lives much easier and we wouldn't have this conversation 

I think we both know how much you helped me understanding more and more of the concept behind jails. I have to read a bit more about jails and devfs.rules(5). So thanks for that advice.


----------



## SirDice (Nov 27, 2019)

deadbeef said:


> You mean mounting a device from the host inside the jails directory tree?


No, I meant allowing mounting from _inside_ the jail itself (allow.mount and related settings).


----------

