Re: Malicious root user sandboxing
On Mon, 25 May 2020 at 14:00, Ihor Antonov wrote: > > I was looking at Capsicumizer and it looks very interesting. > The only reason I was hesitant is that this is an external application, not a > FreeBSD core. Is it going to be included in FreeBSD in some distant future? There are no explicit plans at this point and right now I would describe it as a solid proof of concept - it works well, but only a limited amount of functionality is supported by libpreopen. That said, I would be very happy to see it developed further and become a component of FreeBSD. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Malicious root user sandboxing
On Monday, 25 May 2020 09:37:19 PDT Ed Maste wrote: > On Sat, 16 May 2020 at 20:02, Ihor Antonov wrote: > > Hello FreeBSD Community, > > > > I am looking for possible options to sandbox an untrusted application that > > runs with root privileges. > > > > I can't use Jails or Capsicum as modification of the application is > > outside of the scope of my task and application needs to share the file > > system with some other applications. (several applications use PAM to > > authenticate users and they all have to have the same set of users, and I > > want > > to avoid duplicating system users across jails) > > > > For this write up I will use opensmptd server as an example application, > > but there are many more examples that fit the usecase. > > Is the application dynamically linked? If so it's possible to do > "oblivious sandboxing" with Capsicum. There's a proof of concept in > the "Super Capsicumizer 9000" - > https://github.com/myfreeweb/capsicumizer. It builds on libpreopen > from MUN which handles filesystem access. This is not something that > will work "out of the box" today for your application, but is an area > of active interest that could benefit from a motivating use case. With > some development work (using the approach of capsicumizer + > libpreopen) it could be the basis for a quality sandbox. > > > 1) Application should only be able to listen and talk to TCP port 25. > > > >Initiating connections to other TCP ports and other address families > >must be prevented. > > This would be net new work, intercepting connect(2), accept(2) and > such, passing the args to a socket service, and returning the fd. > > > 2) Application should only have write access to a specific directory, the > > > >rest of the filesystem must be seen by the application as read-only. > > Capsicumizer + libpreopen is most of the way there now. A little work > would be needed to extend it to support different permissions per > directory group. > > > 3) Application should not be able to change it's login class. > > This is inherent in capability mode. > > > 4) Application should not be able to escape the sandbox by forking a child > > > >process. > > Capsicum does not address this, but the child starts in capability > mode and inherits the same sandbox restrictions. The real need then is > for comprehensive resource limits. > > > 5) Application's resource usage must be limited. > > > > 6) Application should not be able to shake-off resource limits by forking > > > >a child or changing login class. > > This probably needs some rctl improvements. > > > 7) Application should not be able to change system configuration, > > load/unload> > >kernel modules, modify firewall rules. > > > > 8) Application should not be able to create new system users, > > > >or change passwords of existing users > > These are inherent in capability mode. Thanks Ed, I was looking at Capsicumizer and it looks very interesting. The only reason I was hesitant is that this is an external application, not a FreeBSD core. Is it going to be included in FreeBSD in some distant future? -- Ihor Antonov signature.asc Description: This is a digitally signed message part.
Re: Malicious root user sandboxing
On Sat, 16 May 2020 at 20:02, Ihor Antonov wrote: > > Hello FreeBSD Community, > > I am looking for possible options to sandbox an untrusted application that > runs with root privileges. > > I can't use Jails or Capsicum as modification of the application is outside of > the scope of my task and application needs to share the file system with > some other applications. (several applications use PAM to authenticate > users and they all have to have the same set of users, and I want > to avoid duplicating system users across jails) > > For this write up I will use opensmptd server as an example application, > but there are many more examples that fit the usecase. Is the application dynamically linked? If so it's possible to do "oblivious sandboxing" with Capsicum. There's a proof of concept in the "Super Capsicumizer 9000" - https://github.com/myfreeweb/capsicumizer. It builds on libpreopen from MUN which handles filesystem access. This is not something that will work "out of the box" today for your application, but is an area of active interest that could benefit from a motivating use case. With some development work (using the approach of capsicumizer + libpreopen) it could be the basis for a quality sandbox. > 1) Application should only be able to listen and talk to TCP port 25. >Initiating connections to other TCP ports and other address families >must be prevented. This would be net new work, intercepting connect(2), accept(2) and such, passing the args to a socket service, and returning the fd. > 2) Application should only have write access to a specific directory, the >rest of the filesystem must be seen by the application as read-only. Capsicumizer + libpreopen is most of the way there now. A little work would be needed to extend it to support different permissions per directory group. > 3) Application should not be able to change it's login class. This is inherent in capability mode. > 4) Application should not be able to escape the sandbox by forking a child >process. Capsicum does not address this, but the child starts in capability mode and inherits the same sandbox restrictions. The real need then is for comprehensive resource limits. > 5) Application's resource usage must be limited. > > 6) Application should not be able to shake-off resource limits by forking >a child or changing login class. This probably needs some rctl improvements. > 7) Application should not be able to change system configuration, load/unload >kernel modules, modify firewall rules. > > 8) Application should not be able to create new system users, >or change passwords of existing users These are inherent in capability mode. ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: ASLR/PIE status in FreeBSD HEAD
On Wed, 20 May 2020 at 03:20, Damien DEVILLE wrote: > > Hi everyone, > > This a very good news. Thanks to Semihalf to their commitment on this subject. > At Stormshield as a security vendor using FreeBSD we are highly interested in > all subjects that enhance the security level of FreeBSD. > What is your target in term of timing ? Are there any plans to work on other > hardening subjects (like for example improving W^X) ? Do you have any roadmap > in terms of features and deadlines ? My goal is that we can test & enable these features in advance of FreeBSD 13.0 (although there's no published timeline for 13 yet). We can aim for iterating over each of the settings over the rest of this year. Basic W^X for mmap and mprotect at the system call interface is trivial - I put a(n untested) patch up at https://reviews.freebsd.org/D24933 as an illustration. There's a TODO in the description before this could be committable - adding procctl(2), proccontrol(1), and ELF tagging support. > We would be interested to take part to live discussions as a vendor if some > are planned. Sounds good. This will make a good topic in lieu of BSDCan developer summit sessions. Interested folks please email me off-list and fill in the poll of suitable times at http://whenisgood.net/qbmg72a ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
