Re: [Wireshark-dev] Wireshark on Kali linux
On Thu, Feb 7, 2019 at 7:51 AM Graham Bloice wrote: > On Thu, 7 Feb 2019 at 10:34, Dario Lombardo wrote: > >> +1 from me for this as well. The warning should be there for anyone not >>> realizing that this is dangerous, but having the option to mute that >>> warning for people who know (or think they do) what they're doing makes >>> sense. >>> >>> My only concern is that if we expect the distribution people to >> deactivate it, and they don't care, we're are not moving. I'd like to have >> something that >> 1) doesn't rely on env variables, cmd line switches, preferences, any >> other stuff related to the way the software is launched, but works >> out-of-the-box. It's ok to rely on the package we distribute (Balint's >> package is not official, but he's a core-, so we're controlling it). If >> other distributions run "as root" and are based on rpm, we should cover >> that as well. >> 2) doesn't bother the users (basically no dialogs). >> > > Surely it has to bother the user in some way, as otherwise there is no > point? I'm not advocating the triple chase-the-dialog really, really > confirm type of dialog, but I do think it should be front and centre. > I hadn't even noticed that the Qt UI *doesn't* provide such a warning. The Gtk one did; for example: https://blog.binarymist.net/2013/04/13/running-wireshark-as-non-root-user/ ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On Thu, 7 Feb 2019 at 10:34, Dario Lombardo wrote: > +1 from me for this as well. The warning should be there for anyone not >> realizing that this is dangerous, but having the option to mute that >> warning for people who know (or think they do) what they're doing makes >> sense. >> >> My only concern is that if we expect the distribution people to > deactivate it, and they don't care, we're are not moving. I'd like to have > something that > 1) doesn't rely on env variables, cmd line switches, preferences, any > other stuff related to the way the software is launched, but works > out-of-the-box. It's ok to rely on the package we distribute (Balint's > package is not official, but he's a core-, so we're controlling it). If > other distributions run "as root" and are based on rpm, we should cover > that as well. > 2) doesn't bother the users (basically no dialogs). > Surely it has to bother the user in some way, as otherwise there is no point? I'm not advocating the triple chase-the-dialog really, really confirm type of dialog, but I do think it should be front and centre. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
> > +1 from me for this as well. The warning should be there for anyone not > realizing that this is dangerous, but having the option to mute that > warning for people who know (or think they do) what they're doing makes > sense. > > My only concern is that if we expect the distribution people to deactivate it, and they don't care, we're are not moving. I'd like to have something that 1) doesn't rely on env variables, cmd line switches, preferences, any other stuff related to the way the software is launched, but works out-of-the-box. It's ok to rely on the package we distribute (Balint's package is not official, but he's a core-, so we're controlling it). If other distributions run "as root" and are based on rpm, we should cover that as well. 2) doesn't bother the users (basically no dialogs). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
Title: Re: [Wireshark-dev] Wireshark on Kali linux On Wed, 6 Feb 2019 at 17:32, Guy Harris <g...@alum.mit.edu> wrote: So the question is whether we should print/pop up a message if TShark/Wireshark is running as root - and, if we do, whether we should have a compile or configuration option to disable that, so it can be disabled on Kali Linux or other OSes where you don't have much of a choice about whether to run them as root. +1 for this. I haven't entirely followed the preceding technical discussion as it's mostly about platforms I have little knowledge about, but this in general seems to be a fair approach. Of course there will be those who have no need to run as "root", who will ignore the advice and disable the warning and continue to run as "root" on the way to ruin. So be it, we will have tried. -- Graham Bloice +1 from me for this as well. The warning should be there for anyone not realizing that this is dangerous, but having the option to mute that warning for people who know (or think they do) what they're doing makes sense. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On Wed, Feb 6, 2019 at 11:26 PM João Valverde < joao.valve...@tecnico.ulisboa.pt> wrote: > > I think a warning for "running Wireshark/tshark as root is dangerous" is > very appropriate. There is a legitimate discussion to be had on whether > it should be more or less forceful and what to do about Kali. > > I agree, but it should not require any feedback from the user (as clicking on a button) or it should be possible to deactivate it. But if we rely on some action on the way it is run (like setting an option or an env var) we could end up to nothing since it is under the control of the distribution, not ours. Something appearing in the toolbar, in the titlebar or in whatever bar sounds good to me, but I guess it should be done from the core, not from init.lua. The 2 changes proposed by Peter sound good to me as well. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On 06/02/19 17:31, Guy Harris wrote: On Feb 6, 2019, at 5:06 AM, Peter Wu wrote: On Wed, Feb 06, 2019 at 12:46:20PM +, João Valverde wrote: 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. OK, so Wireshark and TShark are normally run in some form of user session, whether it's a GUI session or not; in those sessions, there's normally credentials (user and groups) for the logged-in user. (...) So the question is whether we should print/pop up a message if TShark/Wireshark is running as root - and, if we do, whether we should have a compile or configuration option to disable that, so it can be disabled on Kali Linux or other OSes where you don't have much of a choice about whether to run them as root. I think a warning for "running Wireshark/tshark as root is dangerous" is very appropriate. There is a legitimate discussion to be had on whether it should be more or less forceful and what to do about Kali. But throwing a Lua runtime exception for root is not such a warning. That's just a bug in my opinion. Furthermore if a user builds Wireshark without Lua no warning is emitted. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On Wed, 6 Feb 2019 at 17:32, Guy Harris wrote: > > > > So the question is whether we should print/pop up a message if > TShark/Wireshark is running as root - and, if we do, whether we should have > a compile or configuration option to disable that, so it can be disabled on > Kali Linux or other OSes where you don't have much of a choice about > whether to run them as root. > > +1 for this. I haven't entirely followed the preceding technical discussion as it's mostly about platforms I have little knowledge about, but this in general seems to be a fair approach. Of course there will be those who have no need to run as "root", who will ignore the advice and disable the warning and continue to run as "root" on the way to ruin. So be it, we will have tried. -- Graham Bloice ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On Feb 6, 2019, at 5:06 AM, Peter Wu wrote: > On Wed, Feb 06, 2019 at 12:46:20PM +, João Valverde wrote: > >> 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. OK, so Wireshark and TShark are normally run in some form of user session, whether it's a GUI session or not; in those sessions, there's normally credentials (user and groups) for the logged-in user. If Wireshark or TShark is running with the credentials of the logged-in user, it's not running with elevated (or reduced) privileges. It's still not necessarily secure - bugs attackable by maliciously crafted packets, malicious plugins, etc. may still cause it to perform actions, with the logged-in user's privileges, that the user wouldn't want done - but that's a separate issue. In that case, I see no reason to limit where Wireshark looks for plugins, or whether a Lua read-evaluate-print loop (REPL loop), such as Tools > Lua > Evaluate, can be run. On Kali Linux, "the logged-in user" is, apparently, root. Therefore, I don't think we should have a hard policy of "if Wireshark is running with an effective user ID of root, we won't allow a Lua REPL", or "if Wireshark is running with a real user ID of root, we won't allow a Lua REPL". If Wireshark or TShark is *not* running with the credentials of the logged-in user, it's probably running with elevated privileges - although it could conceivably be running with *reduced* privileges, if it's set-UID or set-GID to a user or group with fewer privileges than the logged-in user. I don't think there's an easy way to determine whether you're running with elevated or reduced privileges, unless the credentials you're running with are root on UN*X or an administrator on Windows, in which case the privileges are (almost?) certainly elevated. If it's running set-UID or set-GID on UN*X - I'm not sure Windows has an equivalent - there's no guarantee that the user has an inherent right to perform arbitrary actions with the credentials under which Wireshark or TShark is running; set-UID/set-GID is intended to allow a user to perform *those actions that the set-UID/set-GID program permits the user to perform* with those credentials. As such, if Wireshark or TShark is running set-UID or set-GID: it mustn't be allowed to load shared libraries from directories that the user specifies by, for example, setting an environment variable; it mustn't be allowed to load shared libraries from any directory into which the user can put files; it mustn't be allowed to load shared libraries that the user can modify; it mustn't be allowed to preload special shared libraries or replace individual shared libraries that the user specifies by, for example, setting an environment variable; it mustn't be allowed to run programs from directories that the user specifies by, for example, setting an environment variable; it mustn't be allowed to run programs from any directory into which the user can put files; it mustn't be allowed to run programs that the user can modify; it mustn't be allowed to load compiled plugins or Lua scripts from directories that the user specifies by, for example, setting an environment variable; it mustn't be allowed to load compiled plugins or Lua scripts from any directory into which the user can put files; it mustn't be allowed to load compiled plugins or Lua scripts that the user can modify; etc.,
Re: [Wireshark-dev] Wireshark on Kali linux
On Wed, Feb 06, 2019 at 12:46:20PM +, 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 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
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. 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). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
> 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? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On 05/02/19 23:50, Guy Harris wrote: On Feb 5, 2019, at 2:52 PM, João Valverde wrote: On 05/02/19 16:48, Dario Lombardo wrote: Possible solutions: - don't enable this error for console.lua By which you presumably mean something more general, such as "don't enable this error for scripts that are distributed as part of Wireshark". Something like that, but... The risk with Lua scripts is privilege escalation, meaning running user writable Lua scripts as root. If Wireshark is installed with user-privileges to a user writable prefix, for example PREFIX=/home, and executed with root privileges then that risk still exists for scripts distributed as part of Wireshark and installed to $libdir (but the same is true for binary plugins). - don't try to run dofile(console.lua) if the user is root See previous comment, plus "is there a reason not to run console.lua if the user is root"? Or do you mean "run it with something other than dofile()" (which just removes the "plus" part)? I meant not load it at all with UID 0. Not sure what you are asking here. Doing that will disable some GUI features, this may or may not be acceptable. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On Feb 5, 2019, at 2:52 PM, João Valverde wrote: > On 05/02/19 16:48, Dario Lombardo wrote: > Possible solutions: > - don't enable this error for console.lua By which you presumably mean something more general, such as "don't enable this error for scripts that are distributed as part of Wireshark". > - don't try to run dofile(console.lua) if the user is root See previous comment, plus "is there a reason not to run console.lua if the user is root"? Or do you mean "run it with something other than dofile()" (which just removes the "plus" part)? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On 05/02/19 16:48, Dario Lombardo wrote: Hi Today I found out an annoying issue on kali. It ships with a pretty new version of wireshark, but when you launch it, an issue raises. This post describes the issue and proposes a fix, too. https://securityonline.info/run-wireshark-as-root-kali-linux/?cn-reloaded=1 I know that the problem is how kali runs wireshark (as root) and that it should be avoided, but this is how kali works and I don't think they will change their mind. Moreover from the perspective of a kali user, it really looks like a bug in wireshark and not in kali. I am planning to solve it somehow. What about the solution proposed in the post? I could embed it in the debian package when installed on kali. That would solve the issue, but do we want to do it? And do we want to do it this way? I'd like to hear some opinion. This is a bug in Wireshark. step 1) make dofile() an error if the user is root. step 2) try to run dofile() anyway, even though step 1 made it an error. Possible solutions: - don't enable this error for console.lua - don't try to run dofile(console.lua) if the user is root - use something else other than error() when disabling dofile() (something that won't generate such a disruptive dialog window for example). ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On Feb 5, 2019, at 2:08 PM, Dario Lombardo wrote: > Yes. Kali Linux is a very popular distribution for pentesting. Most of the > software it ships requires root privileges, hence they just use root. OK, so at least they're not doing something stupid such as specifically running Wireshark as root in order to get capture privileges rather than running everything as root, given that running dumpcap as root would suffice in that case. > It is basically a live distro run from cd/USB or in a VM. Usually it's not > installed on the hard drive and when a new version is available it is just > replaced by the new one. The kali community keeps the softwares up to date to > their best, so no need for update the packages. The last version I found > ships wireshark as packed by Balint, v2.6.3. > > Random thoughts: > 1) the solution proposed in the post looks like patching wireshark due to a > bug of it. "It" being Wireshark? The solution proposed in the patch is not to load console.lua. If that change a bug fix, presumably that means we shouldn't be loading (or shipping) console.lua. Should we be doing so, or not? Or is the bug that we disable dofile() etc. even on systems where everything runs as root, in which case we should offer a configuration option "package for systems that run everything as root" and, if that option is enabled, remove the special "if super-user" checks from init.lua. > 3) kali is debian derivative shipping Balint's package. That means that the > solution can be in the software itself (I don't like it very much) or in the > packaging system we control directly (much better, IMHO). 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. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
Yes. Kali Linux is a very popular distribution for pentesting. Most of the software it ships requires root privileges, hence they just use root. It is basically a live distro run from cd/USB or in a VM. Usually it's not installed on the hard drive and when a new version is available it is just replaced by the new one. The kali community keeps the softwares up to date to their best, so no need for update the packages. The last version I found ships wireshark as packed by Balint, v2.6.3. Random thoughts: 1) the solution proposed in the post looks like patching wireshark due to a bug of it. The post shows v2.4 so it looks like it is there since forever. 2) due to the "throw and replace" model, patching the Lua file is just a palliative. As long as the user replaces kali, the error is back. 3) kali is debian derivative shipping Balint's package. That means that the solution can be in the software itself (I don't like it very much) or in the packaging system we control directly (much better, IMHO). 4) no way to change their working model. AFAIK kali just runs this way. You can create an unprivileged account and log in with it, but that's not what the manuals say. Upgrade to a new kali and you're back again with just the root account. At the moment I'm trying to change debian/rules to implement the patching of the Lua file when the package is installed on kali. Let's see where it goes. On Tue, Feb 5, 2019, 19:10 Guy Harris On Feb 5, 2019, at 8:48 AM, Dario Lombardo wrote: > > > I know that the problem is how kali runs wireshark (as root) and that it > should be avoided, but this is how kali works > > Kali Linux has no user accounts, so you log in as root and thus everything > runs as root? > ___ > Sent via:Wireshark-dev mailing list > Archives:https://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark on Kali linux
On Feb 5, 2019, at 8:48 AM, Dario Lombardo wrote: > I know that the problem is how kali runs wireshark (as root) and that it > should be avoided, but this is how kali works Kali Linux has no user accounts, so you log in as root and thus everything runs as root? ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wireshark on Kali linux
Hi Today I found out an annoying issue on kali. It ships with a pretty new version of wireshark, but when you launch it, an issue raises. This post describes the issue and proposes a fix, too. https://securityonline.info/run-wireshark-as-root-kali-linux/?cn-reloaded=1 I know that the problem is how kali runs wireshark (as root) and that it should be avoided, but this is how kali works and I don't think they will change their mind. Moreover from the perspective of a kali user, it really looks like a bug in wireshark and not in kali. I am planning to solve it somehow. What about the solution proposed in the post? I could embed it in the debian package when installed on kali. That would solve the issue, but do we want to do it? And do we want to do it this way? I'd like to hear some opinion. Thanks Dario. -- Naima is online. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
