Re: Lua error while running Wireshark as root (was: Re: Wireshark on Kali linux)

[Peter Wu <peter () lekensteyn nl>]

On Tue, Feb 05, 2019 at 03:47:47PM -0800, Guy Harris wrote:
> On Feb 5, 2019, at 2:38 PM, Peter Wu <peter () lekensteyn nl> wrote:
>
> > On Tue, Feb 05, 2019 at 02:25:58PM -0800, Guy Harris wrote:
> > > On Feb 5, 2019, at 2:07 PM, Peter Wu <peter () lekensteyn nl> wrote:
> > >
> > > > The last option would permit *users* to invoke arbitrary commands as
> > > > root if they run Wireshark with sudo or as root user. I think that might
> > > > not be a bad idea after all:
> > >
> > >    [existing reasons elided]
> > >
> > > - They shouldn't be running *Wireshark* as root unless they're on a
> > > system such as Kali where everything runs as root; if they need root
> > > privileges in order to capture, they should make dumpcap set-UID root.
> >
> > I agree, a warning is already printed by tshark when running it as root.
>
> Depending on whether you have issetugid() or not.
>
> On UN*X, started_with_special_privs() is:
>
> /*
>  * "Started with special privileges" means "started out set-UID or set-GID",
>  * or run as the root user or group.
>  */
> gboolean
> started_with_special_privs(void)
> {
>       g_assert(init_process_policies_called);
> #ifdef HAVE_ISSETUGID
>       return issetugid();
> #else
>       return (ruid != euid || rgid != egid || ruid == 0 || rgid == 0);
> #endif
> }
>
> If you have issetugid(), it just returns what that returns; it's a system call that never fails.  In recent macOS, 
> the comment for the kernel routine is
>
>  * Notes:       A process is considered tainted if it was created as a retult
>  *              of an execve call from an imnage that had either the SUID or
>  *              SGID bit set on the executable, or if it has changed any of its
>  *              real, effective, or saved user or group IDs since beginning  
>  *              execution.
>
> and it returns 1 if the process is "tainted" and 0 if it isn't (it just checks a flag set elsewhere).  Other 
> *BSD-flavored OSes may do the check differently; macOS has a comment that
>
>       /*
>        * Note: OpenBSD sets a P_SUGIDEXEC flag set at execve() time,
>        * we use P_SUGID because we consider changing the owners as
>        * "tainting" as well.
>        * This is significant for procs that start as root and "become"
>        * a user without an exec - programs cannot know *everything*
>        * that libc *might* have put in their data segment.
>        */
>
> I think OpenBSD was the system that introduced issetugid(); all the *BSDs, and macOS, have it.
>
> I'm not sure whether any Linux distributions have issetugid(); I'm not seeing a symbol "issetugid" in Glibc 2.23 or 
> the 4.20.3 kernel.  Solaris might have it.

Linux does not have issetugid() to detect whether the user was *ever*
changed.

> If you log in as root (the Kali Linux case), should *every program you
> run* be deemed as "started with special privileges"?  If not, how do
> you distinguish that from "run with sudo"?

These situations are equivalent, the real and (saved) effective UIDs are
root (uid 0) in all cases. Since relinquish_special_privs_perm cannot
drop to a lower-privileged uid, Wireshark will continue running with
more privileges than necessary.

> Should we consider "running as root" to be "running with elevated
> privileges" even if issetuid() returns 0 (because your program didn't
> get its privileges from set-UID), and issue a UI warning in that case?

issetugid returning 0 is not relevant for (Kali) Linux. Nevertheless,
given that:

 - We recommend dumpcap to be configured with capabilities or setuid.
 - We want to avoid users to run tshark/wireshark as privileged user
   (using any of sudo / setuid / login as root) to reduce the attack
   vector.

then starting wireshark as root probably deserves a warning.
-- 
Kind regards,
Peter Wu
https://lekensteyn.nl
___________________________________________________________________________
Sent via:    Wireshark-dev mailing list <wireshark-dev () wireshark org>
Archives:    https://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev
             mailto:wireshark-dev-request () wireshark org?subject=unsubscribe