Elevating to Administrator (or 'root') with only one file

[Frederick Gotham]

A note on topicality: This post isn't very much to do with C++ itself, but some people who frequent this group might find this of interest as the main PC operating systems MS-Windows, Linux and MacOS can be programmed for in C++.

I've started work again on my network analysis program that I first released back in 2011. My application is a GUI program that uses wxWidgets, and so far I've got it working for Linux (running GTK+), and MS-Windows.

Up until now, the user has had to explicitly run the program as an Administrator (or as "root"). So if they run it as a normal user, it will load up and say "Failed to open network interface". I want to change this. If my program is run as a normal user then I want the user to be prompted to elevate to Administrator (or "root") and to input their password as necessary.

I've already found code online for achieving this in MS-Windows: https://www.codeproject.com/Articles/320748/Haephrati-Elevating-during-runtime

When it comes to Linux, I don't think it's possible to elevate a process to be owned by 'root'. Please correct me if I'm wrong on this. I think on Linux, I will have to have a starter program (which can be run as a normal user) which then tries to run my main application as root.

I've looked a the source code on GitHub for "GParted", the partition manager in Ubuntu, and I can see how it uses a starter script to load the main program. This would be fine for me however there's one condition with my program that I don't want to break:
- My program can be distributed as a single file that does not need to be installed, and it does not make any changes to the computer (specifically, it doesn't write to the hard disk)

So here's what I'm thinking I might have to do on Linux:

(1) I have my main program 'prog'
(2) I write my starter program 'progstart', and I embed the binary hex values of 'prog' inside it as a char array.
(3) When 'progstart' is run, it creates a shared memory object in the Linux files system, and then it maps the raw binary values of my main application into this shared memory object. This shared memory object will be accessible at "/dev/shm/prog_binary". As everything is a file in Linux, I can then set the execution bit on "/dev/shm/prog_binary" and then try to start it as root.

If I can get this to work, it would mean that I can still distribute my application on Linux as a single executable file that doesn't need to write to the hard disk. Oh by the way, I realise that the directory "/tmp" is a RAM disk on most Linux computers but I just want to guarantee myself that I'm using RAM by going with a shared memory object instead.

Any advice or ideas on this?

[Alf P. Steinbach]

On 13.02.2020 14:58, Frederick Gotham wrote:
>
> A note on topicality: This post isn't very much to do with C++ itself, but some people who frequent this group might find this of interest as the main PC operating systems MS-Windows, Linux and MacOS can be programmed for in C++.
>
> I've started work again on my network analysis program that I first released back in 2011. My application is a GUI program that uses wxWidgets, and so far I've got it working for Linux (running GTK+), and MS-Windows.
>
> Up until now, the user has had to explicitly run the program as an Administrator (or as "root"). So if they run it as a normal user, it will load up and say "Failed to open network interface". I want to change this. If my program is run as a normal user then I want the user to be prompted to elevate to Administrator (or "root") and to input their password as necessary.
>
> I've already found code online for achieving this in MS-Windows: https://www.codeproject.com/Articles/320748/Haephrati-Elevating-during-runtime

Relaunching isn't exactly a good way.

There are three main ways to do things:

* Just mark the executable as requiring elevation. Then Windows will
always ask before running it.
* Let it launch another program (not itself) using ShellExecute family.
* Use the COM interface that ShellExecute uses internally, to call a
function in a DLL that you provide, elevated.

> When it comes to Linux, I don't think it's possible to elevate a process to be owned by 'root'. Please correct me if I'm wrong on this. I think on Linux, I will have to have a starter program (which can be run as a normal user) which then tries to run my main application as root.
>
> I've looked a the source code on GitHub for "GParted", the partition manager in Ubuntu, and I can see how it uses a starter script to load the main program. This would be fine for me however there's one condition with my program that I don't want to break:
> - My program can be distributed as a single file that does not need to be installed, and it does not make any changes to the computer (specifically, it doesn't write to the hard disk)
>
> So here's what I'm thinking I might have to do on Linux:
>
> (1) I have my main program 'prog'
> (2) I write my starter program 'progstart', and I embed the binary hex values of 'prog' inside it as a char array.
> (3) When 'progstart' is run, it creates a shared memory object in the Linux files system, and then it maps the raw binary values of my main application into this shared memory object. This shared memory object will be accessible at "/dev/shm/prog_binary". As everything is a file in Linux, I can then set the execution bit on "/dev/shm/prog_binary" and then try to start it as root.
>
> If I can get this to work, it would mean that I can still distribute my application on Linux as a single executable file that doesn't need to write to the hard disk. Oh by the way, I realise that the directory "/tmp" is a RAM disk on most Linux computers but I just want to guarantee myself that I'm using RAM by going with a shared memory object instead.
>
> Any advice or ideas on this?

You know, invoke it as `sudo gork`, where `gork` is whatever program.

Linux users are accustomed to having to use `sudo` to do things of
administrative flavor.

- Alf

[Frederick Gotham]

On Thursday, February 13, 2020 at 2:42:22 PM UTC, Alf P. Steinbach wrote:

> Relaunching isn't exactly a good way.

I didn't look closely at that code, I just brushed past it because I thought it elevated the privileges of the current process. (I'm focusing on Linux right now and I'll get back to MS-Windows later).

> You know, invoke it as `sudo gork`, where `gork` is whatever program.
>
> Linux users are accustomed to having to use `sudo` to do things of
> administrative flavor.

"gksudo" has been removed from Ubuntu.

Anyway, here's the beginnings of the code for the starter program:

#include <stdlib.h>
#include <string.h>
#include <sys/shm.h>
#include <sys/mman.h>
#include <sys/stat.h> /* For mode constants */
#include <sys/types.h>
#include <fcntl.h> /* For O_* constants */
#include <unistd.h>

extern char unsigned const g_prog[3521531u];

int main(void)
{
/* create the shared memory object */
int const f = shm_open("/prog_binary", O_CREAT | O_RDWR, 0666);

/* configure the size of the shared memory object */
ftruncate(f, sizeof g_prog);

/* memory map the shared memory object */
void *const ptr = mmap(0, sizeof g_prog, PROT_READ|PROT_WRITE|PROT_EXEC, MAP_SHARED, f, 0);

/* write to the shared memory object */
memcpy(ptr, g_prog, sizeof g_prog);

/* unmap the memory */
munmap(ptr, sizeof g_prog);

/* Mark the file as executable */
system("chmod +x /dev/shm/prog_binary");

/* Run the main program */
system("/dev/shm/prog_binary");

for ( ; /* ever */ ; )
{
/* Do Nothing */
;
}

return 0;
}

Unfortunately when I try to run this, I get:

sh: 1: /dev/shm/prog_binary: Text file busy

[Frederick Gotham]

On Thursday, February 13, 2020 at 2:53:24 PM UTC, Frederick Gotham wrote:

> Unfortunately when I try to run this, I get:
>
> sh: 1: /dev/shm/prog_binary: Text file busy

I got it to work by adding in:

close(f);

before I try to execute it. It will remain in memory like that until you delete the file "/dev/shm/prog_binary".

[Frederick Gotham]

On Thursday, February 13, 2020 at 2:59:28 PM UTC, Frederick Gotham wrote:

> I got it to work by adding in:
>
> close(f);
>
> before I try to execute it. It will remain in memory like that until you delete the file "/dev/shm/prog_binary".

It displays a GUI interface for the user to enter their superuser password if I change:

"sudo /dev/shm/prog_binary"

to:

"pkexec env DISPLAY=$DISPLAY XAUTHORITY=$XAUTHORITY /dev/shm/prog_binary"

This looks really nice and it's exactly what I'm looking for.

Now... I want to see if it's possible to have my main program in memory just once instead of twice. If you look at my previous code, you'll see that I create the shared memory object, and then I copy the binary data from my global char array into the shared memory object. So if my main application is 4.5 megabytes, then it will take up 9MB of RAM before my main program has made any allocations on the heap. Ideally I would only like to have my program in memory once. It's not the end of the world though if I take up another 4 or 5 more megabytes of RAM considering that my main application overall uses about 5 - 10 megabytes of RAM when running.

[Bonita Montero]

You can give a thread admin-rights by LogonUser with admin
-credentials and then do ImpersonateLoggedOnUser give the
therad the access-rigts of the newly created token.

[Jorgen Grahn]

On Thu, 2020-02-13, Frederick Gotham wrote:
...

> When it comes to Linux, I don't think it's possible to elevate a
> process to be owned by 'root'. Please correct me if I'm wrong on
> this.

You're wrong; there's at least one standard Unix way of doing it, and
maybe some Linux-specific ones, too.

/Jorgen

--
// Jorgen Grahn <grahn@ Oo o. . .
\X/ snipabacken.se> O o .

[Frederick Gotham]

> You're wrong; there's at least one
> standard Unix way of doing it, and
> maybe some Linux-specific ones, too.

Kindly illuminate me.

[Frederick Gotham]

By the way, after thinking about it for a minute... my main application is actually in memory three times. There's the first one when the global data of the 'starter' program is loaded. There's the second one when I copy it into the shared memory object, and there's the third one when I execute "/dev/shm/prog_binary".

[Ike Naar]

man setuid?

[Melzzzzz]

On 2020-02-13, Frederick Gotham <cauldwel...@gmail.com> wrote:
>

https://wiki.wireshark.org/CaptureSetup/CapturePrivileges

--
press any key to continue or any other to quit...
U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec
Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec
Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi
bili naoruzani. -- Mladen Gogala

[jak]

Hi,
you could try this way:

- change owner of your program to root
chown root YourProgram
- change file permission from -r-xr-xr-x to -r-sr-xr-x
chmod u+s YourProgram
- now call setuid system call from main function of you program
with 0 as parameter and the owner of your program will be root.

[Frederick Gotham]

[QUOTE]

By the way, after thinking about it for a minute... my main application is actually in memory three times. There's the first one when the global data of the 'starter' program is loaded. There's the second one when I copy it into the shared memory object, and there's the third one when I execute "/dev/shm/prog_binary".

[/QUOTE]

If I wanted to be a real miser with RAM then I could get my main application to reuse the memory that is wasted by the starter program.

[David Brown]

On 13/02/2020 14:58, Frederick Gotham wrote:

> So here's what I'm thinking I might have to do on Linux:
>
> (1) I have my main program 'prog' (2) I write my starter program
> 'progstart', and I embed the binary hex values of 'prog' inside it as
> a char array. (3) When 'progstart' is run, it creates a shared memory
> object in the Linux files system, and then it maps the raw binary
> values of my main application into this shared memory object. This
> shared memory object will be accessible at "/dev/shm/prog_binary". As
> everything is a file in Linux, I can then set the execution bit on
> "/dev/shm/prog_binary" and then try to start it as root.
>

I can tell you that this is /not/ going to be popular with anyone who
takes their security seriously. You want to create a program on the fly
to run as root, and delete it afterwards? Can you imagine a better way
to make the program look like malware?

> If I can get this to work, it would mean that I can still distribute
> my application on Linux as a single executable file that doesn't need
> to write to the hard disk. Oh by the way, I realise that the
> directory "/tmp" is a RAM disk on most Linux computers but I just
> want to guarantee myself that I'm using RAM by going with a shared
> memory object instead.
>
> Any advice or ideas on this?
>

Yes. Drop the "single executable" idea. It is silly - it offers
negligible benefits at a very high price.

If you want to provide a program that people have to run as root, you
have several sensible options:

1. Provide the program as an archive (tgz, typically). Include an
installer that people have to run as root, that copies the program to a
suitable path (/usr/local/bin is the first choice), makes it owned by
root and sets the setuid bit.

2. Provide the program as an archive or single program, and require the
user to start it as root directly (with sudo or whatever method they
prefer).

3. Provide the program as a deb or rpm (or both).

4. Provide it as a flatpak.

[Frederick Gotham]

On Friday, February 14, 2020 at 9:38:43 AM UTC, David Brown wrote:

> You want to create a program on the fly
> to run as root, and delete it afterwards?
> Can you imagine a better way
> to make the program look like malware?

Noted.

> Yes. Drop the "single executable" idea. It is silly - it offers
> negligible benefits at a very high price.

Have you seen the website "https://portableapps.com/"? I want to have my application up on that website as an application that does not need to be installed (e.g. you can run it from a USB pen drive). To give an example, in the past I've found it very handy to run Mozilla Thunderbird as a portable app on a USB stick so that I can organise and check my emails in an internet café or on a friend's computer.

With that said though, a 'portable' app doesn't need to be just one file. It would be nice if it were just one file though.


<snip>

> Include an
> installer that people have to run as root, that copies the program to a
> suitable path (/usr/local/bin is the first choice), makes it owned by
> root and sets the setuid bit.

<snip>

> 3. Provide the program as a deb or rpm (or both).

<snip>


I think that the best way to keep everyone happy is to provide 5 files with every new release of my application:

source_code.zip
mswin_installer.exe
mswin_portable.exe
linux_installer
linux_portable

So let's say, for instance, that you're running MS-Windows 10 on your desk PC at work. Well, you have the option of using the installer which will do everything the canonical way on Windows, e.g. installing to "C:\Program Files" and setting the file to be run as Administrator, and you also have the choice of using the 'portable' one which you can run from a USB pen drive.

By the way just now I found the coolest header file in the galaxy for embedding a binary inside another binary:

https://github.com/graphitemaster/incbin

[Ralf Fassel]

* Frederick Gotham <cauldwel...@gmail.com>

| Up until now, the user has had to explicitly run the program as an
| Administrator (or as "root"). So if they run it as a normal user, it
| will load up and say "Failed to open network interface". I want to
| change this. If my program is run as a normal user then I want the
| user to be prompted to elevate to Administrator (or "root") and to
| input their password as necessary.

What exactly is your program doing that requires root access?
"Open network interface" can mean many things...

Opening TCP connections sure does not require root access unless you
are trying to provide a TCP server port <= 1024 on Linux...

R'

[David Brown]

(Please get a proper newsreader, or if you must use google groups, get
your line lengths right. For most posts it is not much of a pain, but
when you have formatted text such as code or lists, other posters have
to make a lot of effort when replying if they want to avoid ruining the
formatting.)

On 14/02/2020 11:55, Frederick Gotham wrote:
> On Friday, February 14, 2020 at 9:38:43 AM UTC, David Brown wrote:
>
>> You want to create a program on the fly to run as root, and delete
>> it afterwards? Can you imagine a better way to make the program
>> look like malware?
>
>
> Noted.
>
>
>> Yes. Drop the "single executable" idea. It is silly - it offers
>> negligible benefits at a very high price.
>
>
> Have you seen the website "https://portableapps.com/"? I want to have
> my application up on that website as an application that does not
> need to be installed (e.g. you can run it from a USB pen drive). To
> give an example, in the past I've found it very handy to run Mozilla
> Thunderbird as a portable app on a USB stick so that I can organise
> and check my emails in an internet café or on a friend's computer.
>
> With that said though, a 'portable' app doesn't need to be just one
> file. It would be nice if it were just one file though.
>

Yes, I have seen portable apps. I have found them useful sometimes on
Windows, but never felt the need on Linux. (Perhaps that's because the
main use I have had for portable apps is virus checkers, malware
scanners, and the like, for fixing broken or infected Windows machines.)

Another difference here is that every application installed on Windows
slows the whole thing down, and can't be fully uninstalled - there are
always files left, traces left, registry entries, etc. Portable apps
helps a Windows system avoid accumulating cruft, and can help keep it
workable for longer. This is not an issue on Linux systems, where
programs don't usually have a resource cost when they are not in use.

And again, I am unlikely to want to run a program from a USB stick as
root. And if I really /do/ want to do so, I'd be happy to do it using
sudo or su manually.

I don't know what your program is and who would use it. But I think you
need to think carefully about who will use it, why, and in what
circumstances. Do you really have a large target audience who would
want to run the program as a "portable app" on Linux systems, and who
are not sufficiently technical to handle the "run as root" themselves?

>
> <snip>
>> Include an installer that people have to run as root, that copies
>> the program to a suitable path (/usr/local/bin is the first
>> choice), makes it owned by root and sets the setuid bit.
> <snip>
>> 3. Provide the program as a deb or rpm (or both).
> <snip>
>
>
> I think that the best way to keep everyone happy is to provide 5
> files with every new release of my application:
>
> source_code.zip mswin_installer.exe mswin_portable.exe
> linux_installer linux_portable
>
> So let's say, for instance, that you're running MS-Windows 10 on your
> desk PC at work. Well, you have the option of using the installer
> which will do everything the canonical way on Windows, e.g.
> installing to "C:\Program Files" and setting the file to be run as
> Administrator, and you also have the choice of using the 'portable'
> one which you can run from a USB pen drive.
>
> By the way just now I found the coolest header file in the galaxy for
> embedding a binary inside another binary:
>
> https://github.com/graphitemaster/incbin
>

That's an interesting idea. I've had occasion to include binary files
in my code, but I do it with a simple Python script that turns the
binary into a C file with a const uint8_t array.

[Frederick Gotham]

On Friday, February 14, 2020 at 11:35:52 AM UTC, David Brown wrote:

> And again, I am unlikely to want to run a program from a USB stick as
> root. And if I really /do/ want to do so, I'd be happy to do it using
> sudo or su manually.

Of the 5 files provided with each release, it sounds like you would be one of the folks who go for the linux_installer. Some other dude from another town might go for linux_portable.

> I don't know what your program is and who would use it.

You set it to listen on a network interface and it gives you a long and detailed list of MAC addresses, IP addresses and port numbers observed. You can also send out ARP request in a particular range (e.g. 10.0.0.0/8), and finally you can send what I call an "internet probe" to every observed MAC address to see if you get any reply (thus indicating that the target MAC address is in fact a router with a route to the internet).

> But I think you
> need to think carefully about who will use it, why, and in what
> circumstances. Do you really have a large target audience who would
> want to run the program as a "portable app" on Linux systems, and who
> are not sufficiently technical to handle the "run as root" themselves?

It would be cool if the Ubuntu guys would at some point allow me to add it into their "apt install" system. In this case I would make a .deb file that installs everything the right way on Ubuntu Linux. Right now the translation files (German, Irish) are embedded in the executable file but I can put them in the usual place on Ubuntu.

> That's an interesting idea. I've had occasion to include binary files
> in my code, but I do it with a simple Python script that turns the
> binary into a C file with a const uint8_t array.

I do pretty much exactly the same thing in one of my pre-build steps for my main application, however the "incbin.h" way of doing it is WAY faster at compiling. In my own project, I scan the current directory looking for translation files (*.mo) and country flags (*.png), and then I make char arrays out of each of them, and then these get embedded in my executable. I have automated it in such a way that you just need to add a translation file (e.g. es.mo) and a flag picture (e.g. es.png) to the directory and hit "make" and it pulls it into my main application automagically.

[Ben Bacarisse]

Have you considered posting in group in which the replies you get will
be read and vetted by experts? If not, what is your objection to using
Usenet as it was intended?

(You've had at least one piece of incorrect advice already but in order
to constrain the thread from getting huge and off-topic it may not ever
be commented on.)

--
Ben.

[David Brown]

On 14/02/2020 13:02, Frederick Gotham wrote:
> On Friday, February 14, 2020 at 11:35:52 AM UTC, David Brown wrote:
>

This is all getting really off-topic for this newsgroup. You might do
better in a Linux-specific group or reading some appropriate web resources.

>> And again, I am unlikely to want to run a program from a USB stick
>> as root. And if I really /do/ want to do so, I'd be happy to do it
>> using sudo or su manually.
>
>
> Of the 5 files provided with each release, it sounds like you would
> be one of the folks who go for the linux_installer. Some other dude
> from another town might go for linux_portable.
>

Or I might want to copy it manually to a chosen directory.

>
>> I don't know what your program is and who would use it.
>
>
> You set it to listen on a network interface and it gives you a long
> and detailed list of MAC addresses, IP addresses and port numbers
> observed. You can also send out ARP request in a particular range
> (e.g. 10.0.0.0/8), and finally you can send what I call an "internet
> probe" to every observed MAC address to see if you get any reply
> (thus indicating that the target MAC address is in fact a router with
> a route to the internet).

Anyone who should be using this program can do "sudo" or "su". If they
need hand-holding and point-and-droll interfaces to get superuser
privileges for a program, they should definitely not be doing this kind
of low-level network activity.

I'd even consider /requiring/ that the person be root to run the
program, to make it clear that this is not a toy for amateurs.

>
>
>> But I think you need to think carefully about who will use it, why,
>> and in what circumstances. Do you really have a large target
>> audience who would want to run the program as a "portable app" on
>> Linux systems, and who are not sufficiently technical to handle the
>> "run as root" themselves?
>
>
> It would be cool if the Ubuntu guys would at some point allow me to
> add it into their "apt install" system. In this case I would make a
> .deb file that installs everything the right way on Ubuntu Linux.
> Right now the translation files (German, Irish) are embedded in the
> executable file but I can put them in the usual place on Ubuntu.
>

You don't need permission from Ubuntu to make a deb file. You don't
need permission from them to make a PPP repository that is simple for
Ubuntu users to use. (The same applies to other deb based
distributions, of which Ubuntu is only one, and equally to rpm
distributions and other types of distro.)

Make the deb, check it on a dozen different distros and versions
(VirtualBox is your friend here, especially with snapshots), and then
persuade the Ubuntu distributors to include your deb in their main
distros. (It makes more sense to go via Debian, then Ubuntu can inherit
it.)

Faff around with creating binaries on the fly, and other weird ideas,
and you can be confident that distros will reject it.

[Frederick Gotham]

On Friday, February 14, 2020 at 1:10:48 PM UTC, David Brown wrote:

> Faff around with creating binaries on the fly, and other weird ideas,
> and you can be confident that distros will reject it.

I'll only do this in the 'portable' versions. When it comes to a .deb file for Ubuntu, or an installer for MS-Windows, I will do everything the vanilla way.

[Chris Vine]

On Fri, 14 Feb 2020 02:55:03 -0800 (PST)
Frederick Gotham <cauldwel...@gmail.com> wrote:
>
> Have you seen the website "https://portableapps.com/"? I want to
> have my application up on that website as an application that does not
> need to be installed (e.g. you can run it from a USB pen drive). To
> give an example, in the past I've found it very handy to run Mozilla
> Thunderbird as a portable app on a USB stick so that I can organise and
> check my emails in an internet café or on a friend's computer.
>
> With that said though, a 'portable' app doesn't need to be just one
> file. It would be nice if it were just one file though.

The AppImage format for linux (look it up) is a single file which will
run from any filesystem. Done properly it works well but a lot of
contributor AppImages are total rubbish and don't include all
dependencies correctly. For an example of it done properly, look at the
libreoffice AppImage, which is excellent:
https://www.libreoffice.org/download/appimage/

[Juha Nieminen]

Frederick Gotham <cauldwel...@gmail.com> wrote:
> Up until now, the user has had to explicitly run the program as an Administrator (or as "root"). So if they run it as a normal user, it will load up and say "Failed to open network interface". I want to change this. If my program is run as a normal user then I want the user to be prompted to elevate to Administrator (or "root") and to input their password as necessary.

So a unix user runs your program, the program asks for the root password,
the user quickly kills the program and never runs it again.

No sane person would ever, in a million years, just enter a root password
simply because a program asks for it.

[Jorgen Grahn]

I agree it's a crazy thing to do, but I think systemd and some other
new software (yum?) tries to teach users to happily do exactly this.

Personally I only give it to su(1) or to a local login prompt.

But it's all offtopic here. Comp.unix.programmer would be a better fit.

[Frederick Gotham]

David Brown wrote:

> You want to create a program on the fly
> to run as root, and delete it afterwards?
> Can you imagine a better way to make
> the program look like malware?

<interpostal snip>

> Faff around with creating binaries on the fly,
> and other weird ideas, and you can be
> confident that distros will reject it.

Are you arguing, in general, that a person who has good intentions should refrain from doing something if there is the possibility that an observer might think that they are up to no good?

How do you feel about BitTorrent? Should people who have good intentions avoid using BitTorrent for fear that an observer will think that they're doing something wrong?

The piece of software that I'm writing is a GUI network analysis tool. My application doesn't do anything malicious (like deleting users' documents or scrambling the master boot record) nor does it do anything invasive of privacy or copyright (e.g. copying a user's personal collection of short stories, or online banking passwords, to a remote server). My program is benign.

When trying to implement functionality in my program, it should not matter how much my programming techniques resemble the techniques of a hacker with bad intentions. Loading CPU instructions into a shared memory object to execute it isn't inherently malicious or in any dishonest. It's not like I'm trying to gain root access by deception -- I want the user to willingly enter their password to grant access.

If users were to start emailing me saying that their anti-virus software is quarantining my program, then okay I might have to look into that and maybe even contact the antivirus software company to inform them that their software is generating a false positive on my application. And if the anti-virus company don't reply to me, or if they reply to tell me that they won't relax their detector (nor add my program to an inclusion list) then I suppose I might have to come up with a new idea. Until that happens though, I don't think that I should restrict my own programming techniques because of how much or how little they resemble the techniques of a person with bad intentions. I actually think that the runtime generation of executable code is pretty cool.

By the way, these fanciful techniques like playing around with interprocess memory and so forth are only for the 'portable' versions of my program. I'm happy to also supply the user with a vanilla installer for their operating system that does everything in the canonical way for their operating system if that's what they want.

I think you're being overly and unnecessarily restrictive by advising people not to do something simply because it resembles something bad.

[Jorgen Grahn]

On Sat, 2020-02-15, Frederick Gotham wrote:
> David Brown wrote:
>
>> You want to create a program on the fly
>> to run as root, and delete it afterwards?
>> Can you imagine a better way to make
>> the program look like malware?
> <interpostal snip>
>> Faff around with creating binaries on the fly,
>> and other weird ideas, and you can be
>> confident that distros will reject it.
>
> Are you arguing, in general, that a person who has good intentions
> should refrain from doing something if there is the possibility that
> an observer might think that they are up to no good?

I think he's just saying fewer people will use your software if it
needs root access and at the same time behaves oddly.

[Jorgen Grahn]

On Thu, 2020-02-13, Jorgen Grahn wrote:
> On Thu, 2020-02-13, Frederick Gotham wrote:
> ...
>> When it comes to Linux, I don't think it's possible to elevate a
>> process to be owned by 'root'. Please correct me if I'm wrong on
>> this.
>
> You're wrong; there's at least one standard Unix way of doing it, and
> maybe some Linux-specific ones, too.

I was wrong about this, because I didn't read the question properly.

I was thinking about a user elevating her privileges by executing a
setuid binary or a setgid binary, or doing something similar with
capabilities(7). This includes running su(1), sudo and similar.

You however wanted to elevate the privileges of an existing /process/,
and I have no idea there. I hope it's not possible, except by
exec()ing su(1) or sudo.

[Jorgen Grahn]

On Fri, 2020-02-14, Melzzzzz wrote:
> On 2020-02-13, Frederick Gotham <cauldwel...@gmail.com> wrote:
>>
>> A note on topicality: This post isn't very much to do with C++ itself,
>> but some people who frequent this group might find this of interest as
>> the main PC operating systems MS-Windows, Linux and MacOS can be
>> programmed for in C++.
>>
>> I've started work again on my network analysis program that I first
>> released back in 2011. My application is a GUI program that uses
>> wxWidgets, and so far I've got it working for Linux (running GTK+),
>> and MS-Windows.
>>
>> Up until now, the user has had to explicitly run the program as an
>> Administrator (or as "root"). So if they run it as a normal user, it
>> will load up and say "Failed to open network interface". I want to
>> change this. If my program is run as a normal user then I want the
>> user to be prompted to elevate to Administrator (or "root") and to
>> input their password as necessary.

...

>>
>> Any advice or ideas on this?

> https://wiki.wireshark.org/CaptureSetup/CapturePrivileges

"Wireshark has implemented Privilege Separation which means that
the Wireshark GUI (or the tshark CLI) can run as a normal user
while the dumpcap capture utility runs as root. This can be
achieved by installing dumpcap setuid root. The advantage of this
solution is that while dumpcap is run as root the vast majority of
Wireshark's code is run as a normal user (where it can do much
less damage)."

FWIW, I find what they're doing unacceptable. Their main installation
option lets any local user spy on any other local user's network
traffic, via the setuid 'dumpcap' helper. (Happily Debian doesn't
install wireshark that way by default.)

[Bonita Montero]

> FWIW, I find what they're doing unacceptable. Their main installation
> option lets any local user spy on any other local user's network
> traffic, via the setuid 'dumpcap' helper. (Happily Debian doesn't
> install wireshark that way by default.)

I think it's ok if it it's the root's decision.

[David Brown]

On 15/02/2020 19:02, Frederick Gotham wrote:
> David Brown wrote:
>
>> You want to create a program on the fly to run as root, and delete
>> it afterwards? Can you imagine a better way to make the program
>> look like malware?
> <interpostal snip>
>> Faff around with creating binaries on the fly, and other weird
>> ideas, and you can be confident that distros will reject it.
>
>
> Are you arguing, in general, that a person who has good intentions
> should refrain from doing something if there is the possibility that
> an observer might think that they are up to no good?
>

No, of course not. That would be a ridiculous generalisation.

But I /am/ arguing you should not do something that is entirely
unnecessary for your good intentions, and uses techniques that are
primarily useful for bad intentions. If we were plotting these aspects
of your idea on a graph with one axis on the "looks like good intentions
vs. looks like bad intentions" and the other as "tried-and-tested,
standard and familiar solution to the problem vs. unusual and
experimental solution", then I am suggesting you stay out of the awkward
corner. I am not suggesting you stay off the graph altogether.

> How do you feel about BitTorrent? Should people who have good
> intentions avoid using BitTorrent for fear that an observer will
> think that they're doing something wrong?

That is a very different case. For one thing, there were perfectly
good, legitimate uses for the technology - it was a great way to spread
network costs for large downloads. And any system which provided that
feature for good purposes would also allow it for bad purposes. (Your
suggested solution is not a good one, and better choices can't be abused
for bad purposes.)

But Bittorrent users should be aware that the huge majority of
Bittorrent traffic is for unlawful (or at least suspicious, given that
laws vary from place to place) activity.

>
> The piece of software that I'm writing is a GUI network analysis
> tool. My application doesn't do anything malicious (like deleting
> users' documents or scrambling the master boot record) nor does it do
> anything invasive of privacy or copyright (e.g. copying a user's
> personal collection of short stories, or online banking passwords, to
> a remote server). My program is benign.

I realise it is benign. That does not mean it is a good idea to use
obfuscation techniques that are classic signs of malware.

>
> When trying to implement functionality in my program, it should not
> matter how much my programming techniques resemble the techniques of
> a hacker with bad intentions. Loading CPU instructions into a shared
> memory object to execute it isn't inherently malicious or in any
> dishonest. It's not like I'm trying to gain root access by deception
> -- I want the user to willingly enter their password to grant
> access.

I think you are wrong here. Yes, it matters that you are using such
techniques, for many reasons:

1. You would be alienating potential users - they will avoid your
software as it uses suspicious techniques.

2. You may cause conflict with protection mechanisms (AppArmor, or other
security systems). This means people can't use your software - or
worse, they must open their system to /real/ malware by disabling their
protections.

3. You encourage people to think it's okay to enter their root password
when a program asks for it. That is a bad precedence to set.

4. You show script kiddies how to make malware, since they can copy your
source and put their own malware in it.

You are trying to claim that the ends justify the means. I don't agree
with that. But whether you do agree with it or not, I hope you accept
that when there are simpler, safer and better ways to get the end
result, then these are preferable.

>
> If users were to start emailing me saying that their anti-virus
> software is quarantining my program, then okay I might have to look
> into that and maybe even contact the antivirus software company to
> inform them that their software is generating a false positive on my
> application. And if the anti-virus company don't reply to me, or if
> they reply to tell me that they won't relax their detector (nor add
> my program to an inclusion list) then I suppose I might have to come
> up with a new idea. Until that happens though, I don't think that I
> should restrict my own programming techniques because of how much or
> how little they resemble the techniques of a person with bad
> intentions. I actually think that the runtime generation of
> executable code is pretty cool.
>
> By the way, these fanciful techniques like playing around with
> interprocess memory and so forth are only for the 'portable' versions
> of my program. I'm happy to also supply the user with a vanilla
> installer for their operating system that does everything in the
> canonical way for their operating system if that's what they want.
>
> I think you're being overly and unnecessarily restrictive by advising
> people not to do something simply because it resembles something
> bad.
>

It's your software and your choice. I'll give the advice that I think
is right, but it's up to you to decide.

[David Brown]

That might be okay if you have a tightly run network where only IT staff
have root access to machines. If each user has root access to their own
machines, then this wireshark policy makes it relatively easy to spy on
other traffic on the network.

However, there are so many ways that someone with nefarious plans could
spy on traffic on most local networks, that I think the Wireshark case
is not a problem.

[Frederick Gotham]

On Sunday, February 16, 2020 at 9:43:05 AM UTC, David Brown wrote:

> But I /am/ arguing you should not do something that is entirely
> unnecessary for your good intentions, and uses techniques that are
> primarily useful for bad intentions.

My requirement:
"The 'portable' release binary of my program should exist as one file that does not need to be installed and which does not make any change to the computer which would survive a reboot"

Creating a shared memory object in the Linux file system, and then copying my binary into it, is a way of fulfilling this requirement. Of course though there will also be a "vanilla installer" available for the people who aren't interested in the 'portable' version of my application.

Whether or not something is primarily useful for bad intentions should not influence whether or not we should use it for good intentions -- unless we're dealing with an "availability danger" scenario. To give an example of an availability danger scenario: I live in Western Europe where you can't own a handgun; I think it would be nice if people who have a good use for a handgun (e.g. target shooting for fun) could own one, but if you take into account the consequences of making guns freely available to everyone, then I think it's better if nobody has one at all. I have the same opinion about depleted uranium and various isotopes of plutonium. When it comes to handguns and bomb-making material, I think nobody at all should be allowed have them -- even the people with good intentions.

When it comes to what I'm doing with my program though, i.e. executing code from a shared memory object, well this isn't an "availability danger" scenario.

Whether or not 99% of other people are using an instrument to do bad things should not, as a rule, prevent you from using it for a good reason.

> But Bittorrent users should be aware that the huge majority of
> Bittorrent traffic is for unlawful (or at least suspicious, given that
> laws vary from place to place) activity.

This is what I was hinting at. I could have used another example where they say "Only 0.1% of BLANK are terrorists, but 99% of terrorists are BLANK" but I didn't wanna go there.