Linux capabilities, root ownership and so on

[MarkMLl]

Over the "holiday" I've been investigating a couple of things which required a program to either be owned by root or to have a couple of POSIX capabilities assigned to it so that it could create a unix domain socket in /var/run or create a low-numbered UDP socket. Setuid doesn't work for this sort of thing, since GTK2 (and possibly other widget sets) refuses to run with it even if privileges are relinquished before any GUI facilities are used.

Has anybody else done this in the past, and what is the best way to integrate an operation which requires root privilege (i.e. setcap or chown root) with the IDE's build mechanism?

I was looking at an installation script a few days ago and was slightly horrified to notice that it embedded a whole sequence of sudo operations, the problem being that as far as I know there is no way of explicitly revoking sudo privilege other than waiting for it to time out. I've just been playing with sudo and kdesudo in the context of KDE's konsole and there does appear to be some restriction on its spreading between shells (e.g. different tabs of the same Konsole window), but I still don't entirely trust it.

MarkMLl

[devEric69]

[snip] since GTK2 (and possibly other widget sets) refuses to run with it even if privileges are relinquished before any GUI facilities are used. [snip]

I don't know, if what I'm saying is off-topic.

But, AFAIK, from a "general knowledge" point of view... GTK2 would have Classes for "session management", to save an applications's sate in a predefined user's session.
The classes that manage session rights, are GnomeClient, GConf and GConClient to store the configuration data use by GnomeAPP. And GnomeVFS is used to manage, create and change files, and directories. Then this GTK2 Class can open and close files, read and write, retrieve and could set file information (apparently, the most important function in terms of rights management would seem to be gnome_vfs_get_file_info; and its opposite gnome_vfs_async_set_file_info).

[MarkMLl]

I don't know, if what I'm saying is off-topic.

I'm sure it's not off-topic, but I'm not sure it's right.

Doctrine has it that if you're running with elevated privilege or are using POSIX capabilities (e.g. to bypass all filesystem ownership checks) then you do the dirty work as early as possible and then relinquish those additional rights. In the case of Lazarus I think that means putting the relevant code in the .lpi file.

If you mark a gtk2 program setuid root and try to start it it objects before any of the application code gets a chance to run:

Code: [Select]

$ sudo chmod +s ./x2741-x86_64-linux-gtk2
$ ./x2741-x86_64-linux-gtk2

(process:24046): Gtk-WARNING **: 09:29:31.890: This process is currently running setuid or setgid.
This is not a supported use of GTK+. You must create a helper
program instead. For further details, see:

    http://www.gtk.org/setuid.html

Refusing to initialize GTK+.

I think I spotted that in about 2013, Qt is more tolerant. I'll check, but I think that GTK barfed before anything in the .lpi file was run.

That behaviour provides a strong incentive to investing time in the arcana of POSIX capabilities, but since manipulating them requires root privilege it looks as though it can't be done easily from inside the IDE.

There is one way which might /possibly/ work, and that would be if the final linker stage could be persuaded to overwrite an existing file rather than creating a new one which /might/ inherit the same extended attributes.

MarkMLl

[MarkMLl]

There is one way which might /possibly/ work, and that would be if the final linker stage could be persuaded to overwrite an existing file rather than creating a new one which /might/ inherit the same extended attributes.

Catting over the existing file cancels the capabilities, so it looks as though they have to be set by root every time. I'm not sure whether there's a single capability which could be assigned to the IDE to allow it to set arbitrary capabilities in apps it builds, but in practice that would be as much of a security risk as always running the IDE as root.

MarkMLl

[devEric69]

I always run the IDE with root rights...:

Code: Bash  [Select][+][-]

1. gnome-terminal -e "bash -c 'sudo -i /home/...towards.../lazarus --pcp=/home/guepard/...towards.../primary_config_path_files_config --debug-log=/home/guepard/...towards.../file.log --log-enable=DBG_STATE,DBG_...etc..._BREAKPOINTS'"

...but, as you say, it is a security risk.

[MarkMLl]

Not just a security risk, but a robustness risk since an IDE or compiler could have effects which would normally by caught by access rights.

I think that in principle the IDE could be marked as having the CAP_SETFCAP capability which- I think- is what would allow it to grant capabilities to projects it built, but I'm really not sure that would be a good idea: apart from anything else if a binary was copied from the build directory to a production lcoation it would again need to have  setcap  run on it.

Debian tried using POSIX capabilities on  ping  and  ping6  rather than marking them setuid root. They reverted to setuid after- I think- one release.

MarkMLl

[guest65109]

Invoking gksudo to run a new instance of your program as root and kill the current non-root instance? I'm afraid that gksu might not be installed by default anymore. So we should show a dialog to ask for user password to invoke sudo directly?

[MarkMLl]

Invoking gksudo to run a new instance of your program as root and kill the current non-root instance? I'm afraid that gksu might not be installed by default anymore. So we should show a dialog to ask for user password to invoke sudo directly?

I think I've already said that I'm running KDE, so kdesudo is what's relevant here rather than gksudo. I don't see the fact that neither of those is installed by default to be any significant issue: there are often cases where a program has prerequisites although they're most often libraries.

A more significant issue is the implications of running a program (or worse, telling a customer to run a program) with unrestricted root access, that is after all why the capabilities mechanism was introduced. In addition, there is the problem of making sure that the program reverts to the correct user when it gives up root, and then continues by picking up the correct configuration file etc.

All in all though. it's not such a bad idea: short of giving the IDE the right to grant capabilities when installed it might actually be the best achievable. One possibility- which I'm not exploring this time round- would be to look at how gksu and kdesudo actually work, and to build a component that invokes them and restarts the program as root if some specified capability doesn't exist. It might even be possible to have the same component ensure that root was relinquished after whatever startup that required it had been completed.

MarkMLl

[MarkMLl]

... as I know there is no way of explicitly revoking sudo privilege other than waiting for it to time out.

For the record I think I'm wrong there and that the -k and -K options are there to revoke sudo privilege.

MarkMLl

[PascalDragon]

Assuming that you provide your customer with a compiled package instead of the source, shouldn't setting up the capabilities simply be part of the package's setup routine, which is usually run as priviledged anyway?

And for development you could setup a post compilation command in your project that invokes a script/command to set the capabilities again by using kdesudo or whatever.

[MarkMLl]

Assuming that you provide your customer with a compiled package instead of the source, shouldn't setting up the capabilities simply be part of the package's setup routine, which is usually run as priviledged anyway?

And for development you could setup a post compilation command in your project that invokes a script/command to set the capabilities again by using kdesudo or whatever.

Yes, on reflection I think you're probably right.

MarkMLl

[guest65109]

Assuming that you provide your customer with a compiled package instead of the source, shouldn't setting up the capabilities simply be part of the package's setup routine, which is usually run as priviledged anyway?

And for development you could setup a post compilation command in your project that invokes a script/command to set the capabilities again by using kdesudo or whatever.

Yes, on reflection I think you're probably right.

MarkMLl

OK. I think I only have to put `This program has to be run with root privilege` inside README.TXT and done, I will have no responsible if my program doesn't work or has unexpected behavior when running without root privilege, and I don't have to care about Polkit or Dbus anymore 

[MarkMLl]

OK. I think I only have to put `This program has to be run with root privilege` inside README.TXT and done, I will have no responsible if my program doesn't work or has unexpected behavior when running without root privilege, and I don't have to care about Polkit or Dbus anymore 

I don't think you need to be quite that brutal. If it's your program that needs the extra rights then something like "This program must be started with root privilege, after initialisation it will revert to being run by the owner of the binary". If you need to start a child program as root then explore setuid root, or POSIX capabilities assigned to that program (noting my caveats about what happens if the program is moved or restored from archive). A blanket "run as root" risks making you look dodgy to your customers, or more specifically to a security auditor if they bring one in.

For development/testing, @PascalDragon's point about using kdesudo/gksu, with the caveat that capabilities appear to be lost when a program is run under gdb.

MarkMLl

[guest65109]

OK. I think I only have to put `This program has to be run with root privilege` inside README.TXT and done, I will have no responsible if my program doesn't work or has unexpected behavior when running without root privilege, and I don't have to care about Polkit or Dbus anymore 

I don't think you need to be quite that brutal. If it's your program that needs the extra rights then something like "This program must be started with root privilege, after initialisation it will revert to being run by the owner of the binary". If you need to start a child program as root then explore setuid root, or POSIX capabilities assigned to that program (noting my caveats about what happens if the program is moved or restored from archive). A blanket "run as root" risks making you look dodgy to your customers, or more specifically to a security auditor if they bring one in.

For development/testing, @PascalDragon's point about using kdesudo/gksu, with the caveat that capabilities appear to be lost when a program is run under gdb.

MarkMLl

Oh thank you. I don't want to be rude but English's just not my language 

[MarkMLl]

"You speak a most excellent accent without a trace of English" -- George Mikes, quoting a well-intentioned lady :-)

That's not so much English as customer relations.  Even if a program starts as root it should- ideally- relinquish as many capabilities as possible (the thing that makes root special is that programs it starts have most if not all POSIX capabilities enabled) and you should be prepared to explain to anybody who asks /why/ it needs to run as root.

A program that's still running as root by the time it's listening to a TCP port is asking for trouble- and so's its author.

MarkMLl