svn commit: r251088 - head/crypto/openssh

[Dag-Erling Smørgrav]

Pawel Jakub Dawidek <pjd at 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.

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.

> How does it work on OpenBSD then?

IIUC, they have sandboxing facilities in the base system and use those
instead of the extremely rudimentary rlimit-based implementation that we
use.

> > > Also what is the exact difference between "sandbox" and "yes" settings?
> > "sandbox" enables sandboxing (no surprise) which in FreeBSD's case means
> > 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.

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.

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

Attached.

DES
-- 
Dag-Erling Smørgrav - des at des.no

-------------- next part --------------
A non-text attachment was scrubbed...
Name: openssh-capsicum.diff
Type: text/x-patch
Size: 10790 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/svn-src-all/attachments/20130529/6526a696/attachment.bin>