[OpenWrt-Devel] [PATCH procd v2 0/5] jail work

[John Crispin]

On 27/08/2015 13:25, Etienne Champetier wrote:
> 
> 
> 2015-08-27 12:18 GMT+02:00 John Crispin <blogic at openwrt.org
> <mailto:blogic at openwrt.org>>:
> 
> 
> 
>     On 26/08/2015 18:20, Etienne Champetier wrote:
>     >
>     >
>     > 2015-08-26 15:48 GMT+02:00 John Crispin <blogic at openwrt.org <mailto:blogic at openwrt.org>
>     > <mailto:blogic at openwrt.org <mailto:blogic at openwrt.org>>>:
>     >
>     >     On 26/08/2015 01:00, Etienne CHAMPETIER wrote:
>     >     > This patch series rework a bit ujail,
>     >     > and add capabilities support to it
>     >
>     >     nice
>     >
>     >     >
>     >     > Seccomp filter are very powerful but not totally generic,
>     >     > each arch can have different set of syscalls,
>     >     > each libc can use different syscall for the same function,
>     >     > and seccomp isn't supported on all arch.
>     >     >
>     >     > Capabilities are more high level, but still can restrict
>     >     > jail to a sane minimum of privileges.
>     >
>     >     >
>     >     > Patch 4 is a bit big and i can split it if needed, just tell me how
>     >
>     >     will have a closer look next few days
>     >
>     > forgot to say it's tested on ar71xx with CC (and also on ubuntu 14.04)
>     >
>     >     there seem to be a way to escape from the rebind mount jail that QCA has
>     >     found
>     >
>     > more than one ;) can you share? (with root rights you can kexec, mount
>     > /dev, ...)
> 
>     well if you are root you are root and can delete the bootloader. the
>     idea of the jail is that you are not root.
> 
>  
> Totaly disagree on that.
> Many core program need 1 or a few capabilities, but don't start if you
> are not root
> take for exemple busybox ntpd,
> http://git.busybox.net/busybox/tree/networking/ntpd.c#n2122
> i'm pretty sure it only need CAP_SYS_TIME, but it check for root rights :)
> 
> root give you 2 things:
> all the capabilities,
> read write access on root file
> there is no uid==0 in the kernel, only capabilities check
> 
> If you drop all capabilities, root is a normal user,
> with the exception that he is in general the owner of most or all the file
> (that's when namespaces come into play)
> 
> For me the idea of the jail is to restrict the daemon as much as possible,
> without patching it, so if it need to be root ...
> 


we just need support for the USERNS. i think but there will always be
apps that refuse to start if !root.

i had already added !root support to ubus using ACLs. this allows us to
run at least all the openwrt services in the jail as !root

so lets assume that we can run the majority of apps as !root but i agree
that for the left overs we can implement CAPS support and we also need
CGROUPS support i think. i hjope that i have time at the end of the year
or start of 2016 to add all these.

i think that we should always try to run as !root and only use real root
if there is no technical way to avoid this (and patching lots of
services is not a solution, as in remove the root check form ntp)


> 
>     i will prvide details later on
> 
> cool
>  
> 
> 
>     > that's why you really need to limit rights with capabilities drop or
>     > seccomp filter
>     > (i'm adding a vague warning in usage)
> 
>     why do you want to run a privileged user and restrict is perms rather
>     than just use an unprivileged user ?
> 
> see comment before
>  
> 
> 
>     >
>     >
>     >     and i have not had the time yet to finish my jailfs module.
>     >
>     > with my patches you don't see all the bind mount anymore ("in the host"),
>     > they are only in the jail mount namespace.
>     >
>     > to see the mounts inside the jail you can still do
>     > cat /proc/<jailed process pid>/mounts
> 
>     we dont want rebind mounts at all, they were only an intermediate
>     solution
> 
>  
> why? what's the problem with rebind mounts?
> It work for me TM :)
>  

sure we were also able to boot linux using shell scripts but the current
c  code is nicer i think. having a filesystem level implementation seems
much more powerful and clean to me.

> 
> 
>     >
>     >     it
>     >     runs and loads, i can do mounts and access files inside them using
>     >     normal shell calls. however if is point a jail instance at the
>     >     mountpoint it oops horribly. i suspect that i am either using vfs wrong
>     >     or am missing locking/ref-counting somewhere. i'll throw the code onto
>     >     github later today or tomorrow and post the link. maybe someone with
>     >     more knowledge of vfs can help fix it.
>     >
>     > what problem are you fixing with jailfs? (real question/to be sure there
>     > is no simpler solution)
>     >
> 
>     jailfs is similar overlayfs as it has a lower dir that we overlay but
>     now with changes but with a set of filter rules ... consider it like a
>     firewall for file i/o
> 
> 
> My question is what features does jailfs provides that you can't do now?
> I'm not writing that to criticize or discourage you, just want to know ;)

sure, what i would like to see added in the next months is

* USERNS
* jailfs
* cgroups
* CAPS (new on my list)

and whatever else might be useful.
	
	John


> 
> In any case thanks for your work
> 
> Etienne
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel