Mailing List Archive

Possibly Missing Syscalls from Seccomp Filter
Hi!

I'm investigating the seccomp filter in openssh and I wanted to know
whether the following system calls should be added to the filter:

1. getgroups
-
do_authentication2->dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->getgroups
2. setgroups
-
do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->initgroups->setgroups
3. unlink
-
do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->unlink
4. rmdir
-
do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logide->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->rmdir

Below each system call is a call path that seems feasible. My apologies for
any inconvenience.

Regards,
Shankara Pailoor
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possibly Missing Syscalls from Seccomp Filter [ In reply to ]
On Sun, 30 Jun 2019, shankarapailoor . wrote:

> Hi!
>
> I'm investigating the seccomp filter in openssh and I wanted to know
> whether the following system calls should be added to the filter:

I don't think so - AFAIK all of those only happen in the unsandboxed
monitor process.


> 1. getgroups
> -
> do_authentication2->dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->getgroups
> 2. setgroups
> -
> do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->initgroups->setgroups
> 3. unlink
> -
> do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->unlink
> 4. rmdir
> -
> do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logide->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->rmdir
>
> Below each system call is a call path that seems feasible. My apologies for
> any inconvenience.
>
> Regards,
> Shankara Pailoor
> _______________________________________________
> openssh-unix-dev mailing list
> openssh-unix-dev@mindrot.org
> https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possibly Missing Syscalls from Seccomp Filter [ In reply to ]
Just to be clear the paths include sshpkt_vfatal which could be called in
the child process. Is the reason they are not callable because the
effective user id of the sandboxed process non root?


I've updated the paths below:

1.
do_authentication2->dispatch_run_fatal->sshpkt_fatal->sshpkt_vfatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->getgroups

2.
do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->initgroups->setgroups

3.
do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->sshpkt_vfatal->logdie->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->unlink

4.
do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->sshpkt_vfatal->logide->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->rmdir

On Sun, Jun 30, 2019 at 4:32 PM Damien Miller <djm@mindrot.org> wrote:

>
> On Sun, 30 Jun 2019, shankarapailoor . wrote:
>
> > Hi!
> >
> > I'm investigating the seccomp filter in openssh and I wanted to know
> > whether the following system calls should be added to the filter:
>
> I don't think so - AFAIK all of those only happen in the unsandboxed
> monitor process.
>
>
> > 1. getgroups
> > -
> >
> do_authentication2->dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->getgroups
> > 2. setgroups
> > -
> >
> do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->temporarily_use_uid->initgroups->setgroups
> > 3. unlink
> > -
> >
> do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->unlink
> > 4. rmdir
> > -
> >
> do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logide->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->rmdir
> >
> > Below each system call is a call path that seems feasible. My apologies
> for
> > any inconvenience.
> >
> > Regards,
> > Shankara Pailoor
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev@mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>


--
Regards,
Shankara Pailoor
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
Re: Possibly Missing Syscalls from Seccomp Filter [ In reply to ]
do_cleanup() bails out early for the preauth sandboxed process:

if (!authctxt->authenticated)
return;

so the syscalls you list are not reachable there, moreover each cleanup
action therein relies on the establishment of state that can't happen
in the preauth child, e.g.

if (auth_info_file != NULL) {
temporarily_use_uid(authctxt->pw);
unlink(auth_info_file);
restore_uid();
free(auth_info_file);
auth_info_file = NULL;
}

(there's no way auth_info_file can be set until authentication completes
and the channels layer is sttached.

-d

On Sun, 30 Jun 2019, shankarapailoor . wrote:

> Just to be clear the paths include sshpkt_vfatal which could be called in
> the child process. Is the reason they are not callable because the
> effective user id of the sandboxed process non root?
>
>
> I've updated the paths below:
>
> 1.do_authentication2->dispatch_run_fatal->sshpkt_fatal->sshpkt_vfatal->logdi
> e->cleanup_exit->do_cleanup->temporarily_use_uid->getgroups
>
> 2.do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_
> exit->do_cleanup->temporarily_use_uid->initgroups->setgroups
>
> 3.do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->sshpkt_vfatal->l
> ogdie->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->unlink
>
> 4.do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->sshpkt_vfatal->l
> ogide->cleanup_exit->do_cleanup->auth_sock_cleanup_proc->rmdir
>
> On Sun, Jun 30, 2019 at 4:32 PM Damien Miller <djm@mindrot.org> wrote:
>
> On Sun, 30 Jun 2019, shankarapailoor . wrote:
>
> > Hi!
> >
> > I'm investigating the seccomp filter in openssh and I wanted
> to know
> > whether the following system calls should be added to the
> filter:
>
> I don't think so - AFAIK all of those only happen in the
> unsandboxed
> monitor process.
>
>
> > 1. getgroups
> >     -
> >do_authentication2->dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_exit
> ->do_cleanup->temporarily_use_uid->getgroups
> > 2. setgroups
> >     -
> >do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_
> exit->do_cleanup->temporarily_use_uid->initgroups->setgroups
> > 3. unlink
> >     -
> >do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logdie->cleanup_
> exit->do_cleanup->auth_sock_cleanup_proc->unlink
> > 4. rmdir
> >     -
> >do_authentication2->ssh_dispatch_run_fatal->sshpkt_fatal->logide->cleanup_
> exit->do_cleanup->auth_sock_cleanup_proc->rmdir
> >
> > Below each system call is a call path that seems feasible. My
> apologies for
> > any inconvenience.
> >
> > Regards,
> > Shankara Pailoor
> > _______________________________________________
> > openssh-unix-dev mailing list
> > openssh-unix-dev@mindrot.org
> > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
> >
>
>
>
> --
> Regards,Shankara Pailoor
>
>
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@mindrot.org
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev