[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