Date: Thu, 30 May 2013 07:34:28 +0200 From: Pawel Jakub Dawidek <pjd@FreeBSD.org> To: Dag-Erling =?iso-8859-1?Q?Sm=F8rgrav?= <des@des.no> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, bdrewery@freebsd.org Subject: Re: svn commit: r251088 - head/crypto/openssh Message-ID: <20130530053427.GA1384@garage.freebsd.pl> In-Reply-To: <867gih4ymu.fsf@nine.des.no> References: <201305290019.r4T0JxLE011755@svn.freebsd.org> <20130529070952.GA1400@garage.freebsd.pl> <86zjve3qv2.fsf@nine.des.no> <20130529125052.GA1383@garage.freebsd.pl> <867gih4ymu.fsf@nine.des.no>
next in thread | previous in thread | raw e-mail | index | archive | help
--zYM0uCDKw75PZbzx Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, May 29, 2013 at 05:03:05PM +0200, Dag-Erling Sm=F8rgrav wrote: > Pawel Jakub Dawidek <pjd@FreeBSD.org> writes: > > AES-NI doesn't have to go through kernel at all and doing so is much > > slower. Not sure if our OpenSSL version already has native AES-NI > > support. If not it would be best to upgrade it. This would fix AES-NI > > at least. Other crypto HW that do need kernel driver would still need > > something here. I wonder if CRIOGET can't be done before setting rlimit. >=20 > The CRIOGET ioctl call happens deep inside OpenSSL. There may be a way > to pre-initialize the AES engine, but the unprivileged child doesn't > know which engine to use until after it's sandboxed. BTW. At least OpenSSL in HEAD already supports AES-NI natively. > > How does it work on OpenBSD then? >=20 > IIUC, they have sandboxing facilities in the base system and use those > instead of the extremely rudimentary rlimit-based implementation that we > use. They use systrace and from what I see they don't allow ioctl(2) in systrace policy. No idea then how they talk to the kernel crypto framework. > > > > Also what is the exact difference between "sandbox" and "yes" setti= ngs? > > > "sandbox" enables sandboxing (no surprise) which in FreeBSD's case me= ans > > > a bunch of rlimit settings. > > I thought that simple "yes" setting does chroot to /var/empty, drops > > privileges to sshd user/group and sets rlimit? I'm trying to figure out > > the difference between those two settings. >=20 > In our case, the only difference is that "sandbox" uses setrlimit() to > prevent the unprivileged child from forking, opening files or appending > to open files. I see. > > > > The reason I ask is because I plan to experiment with OpenSSH > > > > sandboxing to use Capsicum and Casper. > > > You still have the patches I sent you? > > Probably somewhere in my INBOX. If you have them handy can you please > > resend them? >=20 > Attached. Thanks! If we want to protect against compromised child allocating too much resources, we could still leave rlimit to deny fork(2) and creating new descriptors. In capability sandbox one can still allocate descriptors using dup(2), socket(2), socketpair(2), etc. Capability mode doesn't protect against DoS. --=20 Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://mobter.com --zYM0uCDKw75PZbzx Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.20 (FreeBSD) iEYEARECAAYFAlGm5OMACgkQForvXbEpPzREIgCgjiwogJwqrrfB0B647PGTZYGF y9sAoLvBYaFaB+i6A62dYcvYA8XH+YGV =HMMI -----END PGP SIGNATURE----- --zYM0uCDKw75PZbzx--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130530053427.GA1384>