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

Etienne Champetier champetier.etienne at gmail.com
Mon Sep 14 18:11:09 EDT 2015


hi,

2015-08-27 13:38 GMT+02:00 John Crispin <blogic at openwrt.org>:

>
>
> 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.
>

Just some random stuffs:

-new in kernel 4.3: ambient capabilities (great explanation in the commits)
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=58319057b7847667f0c9585b9de0e8932b0fdb08
http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=746bf6d64275be0c65b0631d8a72b16f1454cfa1
This allow to keep capabilities across execve, without being root,
so if i've understood it right, i can launch a program as nobody, give him
CAP_NET_ADMIN, and this program can execve 'ip', and we can make it work \o/

-userns are a bit more complicated to setup, but there is great exemples in
https://github.com/netblue30/firejail

-I'll definitly give jailfs a try, but since it's there to add security, it
think it would be great to send it upstream for review before we use it for
everyone

-I don't know the performance overhead of cgroup, but memory cgroup could
be really great for "hungry" softwares like transmission

-And for caps, my patches should do the trick

-we should add an option to set PR_SET_NO_NEW_PRIVS (if we don't use
seccomp),
another option to switch user,
another to launch with strace (/etc/init.d/<aaa> strace),
(and also we need to write the glue code to use all this from the init
scripts)

Good night
Etienne

>
>         John
>
>
> >
> > In any case thanks for your work
> >
> > Etienne
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.infradead.org/pipermail/openwrt-devel/attachments/20150915/eb520331/attachment.htm>
-------------- next part --------------
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel


More information about the openwrt-devel mailing list