Re: Possibly Missing Syscalls from Seccomp Filter

[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

 



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@xxxxxxxxxxx> 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@xxxxxxxxxxx
>       > https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev
>       >
> 
> 
> 
> --
> Regards,Shankara Pailoor
> 
> 
_______________________________________________
openssh-unix-dev mailing list
openssh-unix-dev@xxxxxxxxxxx
https://lists.mindrot.org/mailman/listinfo/openssh-unix-dev




[Date Prev] [Date Next] [Thread Prev] [Thread Next] [Date Index] [Thread Index]

[Index of Archives]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Asterisk Internet PBX]     [Linux API]

  Powered by Linux