2

I recently started trying openSUSE 12.3 after having used Ubuntu for a few years. I'm still getting used to openSUSE's treatment of su (and sudo) vs. Ubuntu's use of sudo. I've been reading the openSUSE manual, but can't figure out answers to two related questions:

1) In a previous question at https://askubuntu.com/questions/236859/are-there-adverse-effects-from-or-a-better-way-than-writing-to-run-or-dev-sh, I asked about writing a decrypted gpg file temporarily to /run using the gpg --output flag so that the decrypted file would never touch the hard disk. In order to write to /run, however, I needed to use sudo in Ubuntu (i.e., sudo gpg --output '/run/temporary_file_name' etc.).

When I try to do the same thing in openSUSE (using either sudo or su), I get an error message from gpg, presumably because the root user cannot see my user account's gpg keys. Can this use of ``sudofrom Ubuntu, in whichsudoseems to use the same preferences / gpg keys as the regular user, be replicated in openSUSE? I could usegpg etc. | tee etc.`, I suppose, but that seems unwieldy compared to Ubuntu's way of doing things.

2) I have several bash scripts from Ubuntu that require root privileges for some, but not all, lines (e.g., copying files that I don't want to get owned by root, but then installing new software, which requires root privileges). In Ubuntu, I could just have some lines start with sudo. sudo some_command doesn't always seem to work in openSUSE, though. Is the best way to adapt these scripts for openSUSE to use su -c 'command' on those lines of the script? If I use su by itself in the script, the script stops working after I enter the root password.

Please note that, while I'm asking about openSUSE specifically, this question presumably applied to many non-Ubuntu distros.

Community
  • 1
J L
  • 1,183

3 Answers3

2

Whether sudo preserves the HOME environment variable or sets it to the target user's home directory depends on its configuration (see the manual for details). It's not Ubuntu doing it right and SuSE doing it wrong, or vice versa: there are upsides and downsides to both choices. It's your job as a script writer to cope with both cases. The solution to (1) is to either run sudo -H or pass --homedir to gpg.

However, running gpg as root is definitely the wrong approach. This gives gpg too many privileges, and may the privilege to access ~/.gnupg away from it (e.g. if the user's home directory is on NFS). Run gpg as the user who owns the key, and make it print the data to standard output. Piping into tee is the standard way to output to a file that you need special privileges to write (I have no idea why you consider it “unwieldy”):

gpg -d foo.gpg | sudo tee /run/foo

Whether su or sudo is needed to become root depends on the system administrator's choice. Different users on the same machine may use one or the other. Unless you control the configuration on all machines you'll run your script on, allow for both possibilities (e.g. with an option passed to your script).

If your scripts work on Ubuntu with sudo but fail on other distributions or with su, you may be relying on the environment being (almost) completely reset. That's the default sudo configuration on Ubuntu but other systems may behave differently. Fix your script so that it doesn't depend on the environment being reset.

Community
  • 1
Gilles 'SO- stop being evil'
  • 829,060
  • @ Giles, thank you for your explanation. Until switching away from Ubuntu (which I've used for several years without trying anything majorly different), I never understood that sudo has so many intricacies. I appreciate learning that there's a whole world of non-Ubuntu linux security approaches out there for me to read up on. I didn't know that major differences existed.

    I've been doing some reading on sudo environments, and I'm still having trouble understanding what environment variables are/do. Could you recommend some good webpages to me? The man sudo page still leaves me confused.

     – J L Apr 04 '13 at 07:15
  • Also, knowing that using tee is standard makes me feel better about using it. I had previously come to the (perhaps uninformed) impression that it was a non-standard approach that could cause problems somehow. Again, this is very helpful. Thank you! – J L Apr 04 '13 at 07:17
  • @JL The sudo man page is indeed a difficult read. It doesn't help that the program has a lot of configuration options at both compile- and run-time. Environment variables like HOME, PATH, … influence the behavior of a program and this can have security implications (e.g. PATH determines what other programs the app will end up running). Sudo can be configured to set them to safe values, and that's the default configuration on Ubuntu. – Gilles 'SO- stop being evil' Apr 04 '13 at 11:30
  • @ Gilles, thank you. I'm still confused, but think that I'm slowly getting the idea more. I appreciate your explanation.

    So is this issue related to why it's better (as I understand) to run su - instead of su when activating root privileges? Because su - imports the correct environment variables for root, while su doesn't, leading to inability to, e.g., run GUI programs?

    On that note, then, following my question #2 in the original post, for a script that just needs root privileges for a line or two (e.g., to run zypper install, would it be appropriate to use su - -c 'foo'?

     – J L Apr 04 '13 at 20:54
1

This is primarily an answer to question 1 since the other is a separate question that I don't have time to address right now.

Ubuntu takes some shortcuts on security to appeal to typical desktop users who don't want or need the added complexity of full privilege separation. However, if you are handling data that is so sensitive that you don't want to write it to disk, then you are not such a user and should not bypass the standard security architecture by implementing Ubuntu-style sudo rules.

WARNING: Just because you put something in RAM doesn't mean no one else can get to it. The most obvious culprit is on-disk swap, which can end up storing the contents of what was on the RAM indefinitely. But other compromises are possible as well.

So if you've disabled your swap partition and consider that good-enough:

A better option than writing to /run is probably creating your own tmpfs mount owned by the user whose going to use it. For example, if your user and group IDs are both 500:

mount -t tmpfs tmpfs /home/jl/realtmp -ouid=500,gid=500

This command will have to be run as root, but once you have perfected this setup, you can add it to your fstab to make it permanent:

tmpfs   /home/jl/realtmp    tmpfs   uid=500,gid=500 0   0
depquid
  • 3,891
  • @ depquid, I hadn't considered creating a new tmpfs for my gpg decrypted files -- thank you for that suggestion!

    I do have a question about your suggested approach: my understanding is that tmpfs mounts can use swap (which I have enabled, although it is encrypted), while ramfs mounts can't. For that reason, ramfs seems like a potentially more secure solution of the two. However, ramfs mounts seem always to be owned by root (at least in the tests that I did today). Out of curiosity (if that's correct), why is that? Is my understanding of the differences between the two correct?

     – J L Apr 04 '13 at 07:22
  • I'm really not familiar with ramfs but it may be a solution, pending caveats. One way around the ownership limitation is to make it world writable and set the sticky bit, just like /tmp, using chmod 1777. You could put this chmod command in the local init script. – depquid Apr 04 '13 at 11:59
  • @ depquid, interesting! I'll try that out, too! – J L Apr 04 '13 at 20:47
-1

I would enable sudo. This is done by editing /etc/sudoers file and adding the line user ALL=(ALL) ALL. With the desired user. This has to be done as root.

mkkohls
  • 1
  • 1
    @ mkkohls, that line seems already to be enabled by default. The lines in question in /etc/sudoers read

    ## In the default (unconfigured) configuration, sudo asks for the root password. This allows use of an ordinary user account for administration of a freshly installed system. When configuring sudo, delete the two following lines: Defaults targetpw # ask for the password of the target user i.e. root ALL ALL=(ALL) ALL # WARNING! Only use this together with 'Defaults targetpw'!

     – J L Apr 03 '13 at 19:06