Hi again,
2016-05-18 10:22 GMT+02:00 Ferry Huberts <maili...@hupie.com>: > > > On 18/05/16 10:03, David Lang wrote: >> >> On Wed, 18 May 2016, John Crispin wrote: >> >>> On 18/05/2016 09:46, Ferry Huberts wrote: >>>> >>>> >>>> >>>> On 18/05/16 09:25, John Crispin wrote: >>>>> >>>>> >>>>> >>>>> On 18/05/2016 09:21, Radu Anghel wrote: >>>>>> >>>>>> /* sending again because i hit 'reply' instead of 'reply all' :) */ >>>>>> >>>>>> On Wed, May 18, 2016 at 8:29 AM, John Crispin <j...@phrozen.org> >>>>>> wrote: >>>>>>> >>>>>>> >>>>>>> ok, there had been some discussion about building a super daemon that >>>>>>> runs, then ld-preloading bind() and co and using ubus to transport >>>>>>> sockets around. using caps or /proc sounds like a good i between >>>>>>> until >>>>>>> such a daemon exists >>>>>>> >>>>>> >>>>>> Most daemons I know of that need to bind to ports <1024 start as root >>>>>> and after binding to the port they drop privileges to the privileges >>>>>> of the user specified in their config file. For those daemons just >>>>>> adding a user and specifying it in their config file should be enough. >>>>>> For the daemons that don't need to bind to <1024 just starting them >>>>>> from their own user account is ok as they don't need additional >>>>>> privileges. >>>>>> >>>>>> For example the dnsmasq daemon has these options: >>>>>> >>>>>> # If you want dnsmasq to change uid and gid to something other >>>>>> # than the default, edit the following lines. >>>>>> #user= >>>>>> #group= >>>>>> >>>>>> I don't think that integrating such functionality in ubus or some >>>>>> other LEDE-only super-daemon is a good idea. Config options + >>>>>> capabilities for those daemons withut such options is a good way of >>>>>> doing this in my opinion. Also use different users for different >>>>>> daemons, as others said. >>>>> >>>>> >>>>> to elaborate, imagine dnsmasq running inside a jailm where ut only >>>>> thinks it is root but is not in reality. also ld-preloading bind and >>>>> connect would allow us to do pretty adavnced stuff like only allowing >>>>> dnsmasq to open certain ports. essentially an acl around the >>>>> bind/connect calls. >>>>> >>>> >>>> >>>> You might just as well switch on SELinux and use the policies that are >>>> already in-place in Fedora and RedHat/CentOS. >>>> >>>> You then get even stronger protection and run-time performance impact is >>>> negligible. >>>> >>> the stuff i proposed has not runtime hit. selinux is simple to full > > > SELinux's hit is for all intents and purposes zero as well nowadays. > >>> blown and hard to maintain. the idea would be to create a custom >>> tailored solution for our requirements. >> >> >> That is why I prefer AppArmor, you don't have the interaction between >> different application configs that you do with SELinux, so you can focus >> on the specific application that you are concerned about. > > > AppArmor is significantly less secure than SELinux. > And with SELinux you don't need all the preloading stuff that was talked > about, you can just declare which ports are allowed. > >> >> SELinux configs that Fedora uses have to be so permissive to keep from >> breaking too many 'normal' use cases that I really question how valuable >> they are. > > > And this is based on what exactly? > I've been using Fedora ever since SELinux was first enabled and I don't see > that. Processes are well secured. > If you think about stuff like Firefox, then ok, that one is really hard to > secure, better run it in a sandbox. > But process that are well-defined in behaviour are well secured. > > > >> >> A SELinux system tuned by an expert is going to be more secure than an >> AppArmor system tuned by an expert, SELinux just can do more (at least >> right now). But there aren't many experts of that caliber around. A >> reasonably competent sysadmin can understand an AppArmor config and >> tweak it for their layout without too much effort (once they identify >> that AppArmor is blocking what they are trying to do) >> > > > Agreed, it is a balance. > > However, I must note that I've encountered very few cases where the policy > had to be tweaked, on my laptops, desktop and most of all servers. > > One example of tweaking is when I move a service to a different port. > That is a single command, like (moving the port of the 'cockpit' service): >> >> semanage port -a -t websm_port_t -p tcp "$newport" > > > > > My 2 cents :-) Before talking about AppArmor vs SELinux, can someone take a look at the userspace tooling size requirement ? For exemple SELinux tools are mostly Python scripts Etienne > > > > > >> David Lang _______________________________________________ Lede-dev mailing list Lede-dev@lists.infradead.org http://lists.infradead.org/mailman/listinfo/lede-dev
