On Wed, Feb 06, 2019 at 12:46:20PM +0000, João Valverde wrote:
>
>
> On 06/02/19 09:08, Dario Lombardo wrote:
> > > This would mean that they'd have to build Wireshark differently from
> > the default way it's built, using the "package for systems that run
> > everything as root" option. That means a standard Debian package, built
> > to run on a system where you *don't* run everything as root, so that you
> > can leave the safety checks in place, won't be appropriate for Kali.
> >
> > I was thinking to something like maintaining a list of debian derivative
> > that have just the root account (the version checked with lsb_release)
> > and run something on them during the installation phase.
> >
> > > - use something else other than error() when disabling dofile()
> > > (something that won't generate such a disruptive dialog window for
> > example).
> >
> > That was my first try. Something like error -> warning, but I didn't
> > find anything useful. Are you aware of something?
> >
>
> I'm not aware of anything out-of-the-box. It would probably require some UX
> work in Qt to make this notification more user-friendly.
Any dialog would be equally annoying. Perhaps there is a way to push a
statusbar message, but honestly I don't think Lua is the appropriate
place to warn about some stupid behavior.
So tshark already prints a warning when started as (setuid) root. The
GUI does not. It could be modified to show a dialog, but it should
probably also present a "Do not mention this again" checkbox for systems
like Kali Linux where running everything as root is the norm.
> I have some doubts about the effectiveness and usefulness of this Lua
> sandbox. I didn't investigate in depth but it seems enabling/disabling the
> Lua runtime instead would be better, as dictated by policy (whatever that
> policy is).
Setting "enable_lua = false" (formerly "disable_lua = true") already
prevents further Lua code from being executed. Likewise when
"run_user_scripts_when_superuser" is false and when started as root.
I also question the utility of disabling the API, hence these patches:
wslua: do not load console.lua when run as root
https://code.wireshark.org/review/31912
wslua: do not partially disable the Lua API when run as root
https://code.wireshark.org/review/31913
The first patch can be safely be backported and should fix the issue
raised by Kali Linux users. Worst-case, it disables the GUI menu option,
but it has no effect otherwise.
The second patch removes the security theatre, but depends on the first
patch to effectively restrict execution of arbitrary user-supplied code.
It enables arbitrary execution of user-supplied code by default since
those who execute "tshark -Xlua_script:foo.lua" as root user (or via
sudo) will expect it to work.
Finally, note that "started_with_special_privs()" also returns TRUE even
if the current user has no more privileges. Even if the Wireshark or
tshark executables were setuid root, these root privileges have already
been dropped via "relinquish_special_privs_perm()", long before it ever
gets to the Lua code.
--
Kind regards,
Peter Wu
https://lekensteyn.nl
