Circumnavigate fog user issues

[george1421]

First let me say I’m going to mark this post as deleted so that only mods and above can see it. The deletion is intended to just hide the post from the general community and not that it doesn’t have value.

Since this IS the holiday season, I would like to create George’s wish list for FOG 1.6 to help on the support side. @Developers

1. Force the installer to provide a database password for root in mysql. Don’t continue to support a blank password for root access. If root’s password is current blank on the current install, force it to be set to something by the user in the installer. Its a bad security practice to have blank passwords. On the support side we continue to fight with ubuntu who is trying to enforce better security practices (rightly so).
2. Change the default webgui admin account from fog and password to fog and a password defined by the fog admin when fog is installed. This fog installer supplied password shouldn’t need to be stored in the .fogsettings file.
3. Change the fog service account from fog to fogsvc to avoid confusion with the webui user of the same name. This will also eliminate the issue where people follow some pretty crappy instructions on the internet that says to create a user account called fog and then install fog with that account. Then they wonder why they get locked out of the fog server linux account. We can either choose to abandon the linux user fog’s account or set it to no login. I don’t recommend deleting it from the linux system. If the password was defined by the fog installer it should be complex enough. If the fog admin changed it for some reason then its not FOG’s problem then. There will be an issue with file ownership if the service account is changed to fogsvc from fog, so that will need to be taken into account.

These changes should be implemented on existing as well as new installations. I know there is a risk for legacy installs where this security policy change could break things. As long as the changes are communicated to the fog admins beforehand they should be able to adapt since THEY are providing the passwords for both the database as well as the webui. I feel that FOG Project needs to do what it can with the resources available to implement better security practices out of the box.

[Sebastian Roth]

@george1421 Thanks heaps for bringing this up! I will continue to answer in a minute… Ok, deleted mine as well to not confuse anyone.

I don’t see your points as something we need to delay for FOG 1.6 but could possibly bring into 1.5.x already as a testing stage.

1. Force the installer to provide a database password for root in mysql. […]

Absolutely! Funny but I have started looking into this already before Christmas as I really would like to have FOG enforce secure passwords for exactly the same reasons. I just have not found enough time to think it through and test things. I’d even go as far as creating a FOG database user to be used (good practice) but still enforce passwords for root and fog DB user! Will look into that in the first days of 2019.

2. Change the default webgui admin account from fog and password to […]

I am with you here about the default password. But as we have briefly discussed in another thread I tend to rename the FOG web UI user (instead of the fog linux account). Maybe default to admin but even make it so people can choose their own.

3. Change the fog service account from fog to fogsvc to avoid confusion with the webui user of the same name […]

As mentioned above I’d prefer renaming the web UI account name and leave this one. I’d still force the account to be no-login! I need to think more about how we prevent users from using this account like create it beforehand and then being locked out or if they do use it right now on an existing installation. There are options like checking wtmp and stuff to see if the account has been used for login and warn the user but I have not gone into depth here.

@george1421 Let’s see if we can discuss this a different way other than through hidden posts. Might move the discussion a chat session here in the forums or to slack.
@Tom-Elliott What are your thoughts on this? Would be great to get your comments on this topic before I start changing this in 1.5.x already.

[Sebastian Roth]

Thinking a bit more about this I am wondering if we could get rid of the local user account altogether by using vsftpd virtual users. This is untested yet and I might have missed something here. Possibly access rights could cause us trouble here but as we usually set directories to 777 (not great!!) it wouldn’t be any worse than what we have right now.

[Tom Elliott]

@Sebastian-Roth Virtual users still require “physical” home drive locations.

I’ve used VSFTPD in virtual user mode and while it works and can be managed via mysql, it still requires physical access. Usually to a single user which new virtual user folders get generated.

Using the virtual user mode would mean we still have a local account, but with some robustness involved that allows us to limit access to specific virtual users.

I don’t know what method is better (one way or the other).

[Sebastian Roth]

@Tom-Elliott You are right, we probably still need some local system user account anyway. I started playing with it a bit and couldn’t get it to work because of PAM lib issues. Would make it all just way more complicated and error prone so we won’t go there.

As @george1421 states that he’s see several tutorials out in the wild telling users to create an account fog and using that to install we want to move away from that account name and make it a system account (no login allowed). Restricting shell/SSH login is fairly simple but for X login I have not found a general way to restrict login for certain users. The best I could fine is here but needs a modification of the specific login manager (gdm, kdm, xdm, lightdm, sddm, …??) PAM configuration file. This can go wrong in so many ways that I don’t think it’s even worth trying.

Just changing the account name to something different without restricting login (including GUI login!) is not solving the issue but might just add to the confusion of new users.

Should we start by renaming the web UI default user name (e.g. to admin) and change to a auto-generated password? Do you consider this being anything worth in terms of causing less confusion?

[Tom Elliott]

@Sebastian-Roth nearly any web GUI account uses a default user and default password. I suppose we could ask the user what account they’d like to name it and assign a password at install time, this isn’t too hard. That said should this be a GUI and Local user or one or the other? Too many questions too think of.

What might help is detecting if the fog local user already exists, and if so present the user with the question asking what it’s password is set to. If the fog local user doesn’t already exist, create it and set using a random password. Should this also be what we set the GUI user for then? If so how do we ensure the user knows this password?

Just my ramblings but hopefully brings a little insight and or innovation?

[Sebastian Roth]

@Tom-Elliott Thanks for your thoughts on this. I was looking at it from the other side. Try to entangle FOG ftp system account and web GUI account for less possibility to cause confusion.

Checking if system account already exists and has been used to logon is probably a first step towards warning the user. I am not sure but I think a general way to check last logon (terminal, GUI, SSH but not ftp logon I hope) does exist.

[george1421]

@Sebastian-Roth said in Circumnavigate fog user issues:

we want to move away from that account name and make it a system account (no login allowed)

The only thing we need to check is if you disable interactive login, does that also block FTP access? I’m suspecting no, but we should at least test it to confirm. I’m not seeing a risk if we simply abandon the current fog linux account because it should have a secure password by default. If the IT admin had changed it post FOG install then its only as secure as the IT admin set the password to.

On the negative side, I’m not sure about the interactions with a Master/Storage node configuration if only one component of that configuration is updated. Will that break something? While I haven’t kept track of the status, (I’m guessing) I’m seeing (on average) one post per week where the end results was someone fiddled with the fog service account’s password or complains that they were locked out of the FOG server after installing fog.

[Sebastian Roth]

@george1421 said in Circumnavigate fog user issues:

The only thing we need to check is if you disable interactive login

Can you be more precise on this point. How do you disable interactive login? As far as I know there are half a dozen ways of doing this and none is doing it for shell/SSH and GUI at the same time.

interactions with a Master/Storage node configuration

Definitely a good point that we have to keep in mind!!!

[george1421]

@Sebastian-Roth said in Circumnavigate fog user issues:

shell/SSH and GUI at the same time

Who uses a GUI?? This isn’t MS Windows is it?

I can only speak for centos, but placing “/sbin/nologin” on the shell column of the password file should disable at least console (ssh) login. I would be surprised if the GUI ignored this parameter. I might have to spin up a centos install with a gui to test. On the other hand at what level do we go to, to protect the FOG admin from him/her self?

I think the users are most confused between the web ui admin fog and the linux service account called fog. Changing one or both may at least resolve this specific confusion.

[Sebastian Roth]

@george1421 said in Circumnavigate fog user issues:

but placing “/sbin/nologin” on the shell column of the password file should disable at least console (ssh) login. I would be surprised if the GUI ignored this parameter.

I only got as far as testing this on a OpenSuSE installtion that I had at hand and that would surely not login. But it wouldn’t print out a message to the user either. GUI login just seemed to freeze. People who don’t know how to kill the X server (crtl+alt+backspace) and use the terminals to fix things are totally lost with this and will post questions in the forums as before.

On the other hand at what level do we go to, to protect the FOG admin from him/her self?

From what I get in the forums most users running into this are very much inexperienced Ubuntu starters. Many if not all of them use the GUI to start off. Sure I would never ever advice such a thing but this is what you see in a couple of FOG beginner tutorial videos out there.

I think the users are most confused between the web ui admin fog and the linux service account called fog. Changing one or both may at least resolve this specific confusion.

I am definitely with you on this point!

[Sebastian Roth]

I just fear we make it worse not better… This is why I keep asking before making the changes to the code.

[Sebastian Roth]

Thinking a bit more about this I reckon we don’t really want to fully lock that account. It might even cause more people to ask in the forums. Better we try to inform the user as soon as we detect someone is using the account. And I mean informing beginners in particular. So for me it boils down to a couple of places we need to check and take care to inform the user.

1. Fresh install - check if account already exists and setup a new account for the user in case it does - prompting for name and password and explaining why we do this.
2. Upgrade with .fogettings (and therefore fog account) existing - check if the account was ever used to login on the machine (last | grep "^fog" and lastlog -u fog should do the job) and again setup a new account for the user - prompting for name and password and explaining why we do this.
3. Print out a message to the user when opening a shell/terminal or login as fog user (~/.bashrc seems most appropriate to me)
4. Print a X dialog when a user logs in as fog user (~/.config/autostart/ seems to be standard, works great with Ubuntu - anyone can try other distros as well?)

mkdir -p /home/fog/.config/autostart/
cat >/home/fog/.config/autostart/warnfogaccount.desktop <<EOF
[Desktop Entry]
Type=Application
Name=Warn users using the fog account
Exec=/opt/fog/warnfogaccount.sh
Comment=Warn users who use the fog system account to logon
EOF
chown fog:fog /home/fog/.config/autostart/warnfogaccount.desktop
cat >/opt/fog/warnfogaccount.sh <<EOF
#!/bin/bash
title="FOG account"
text="You seem to be using the 'fog' system account to logon and work \non your FOG server system.\n\nIt's NOT recommended to use this account! Please create a new \naccount for administrative tasks.\n\nIf you re-run the installer it would reset the 'fog' account \npassword and therefore lock you out of the system!\n\nTake care, \nyour FOGproject team"
z=$(which zenity)
x=$(which xmessage)
n=$(which notify-send)

if [[ -x $z ]]
then
    $z --error --width=480 --text="$text" --title="$title"
elif [[ -x $x ]]
then
    echo -e $text | $x -center -file -
else
    $n -u critical "$title" "$(echo $text | sed -e 's/ \\n/ /g')"
fi
EOF
chmod 755 /opt/fog/warnfogaccount.sh

[Sebastian Roth]

Ok, somehow lost track of this. Want to add this before a next release… reminder

[Sebastian Roth]

@Tom-Elliott I might find the time to add this to 1.5.x on the weekend. Just wanted to ask if you think this is a good way to go so we do things in line for 1.6.x as well and people don’t get confused.

@george1421 mentioned that from his point of view it would be a good idea to still rename the Linux account to fogsrv or something like that. Should we really? What do we do with existing installations? Leave the old account alone and create a new one or rename and lock it?

[george1421]

@Sebastian-Roth said in Circumnavigate fog user issues:

Leave the old account alone and create a new one or rename and lock it?

IMO Yes, abandon it in place. If fog set the password on that account then we know its pretty secure (or at least complex enough). If the FOG Admin changed the password on the fog linux account then there is not much we can do about security if they set the password to something like password. Either way abandoning it is the best move from my perspective.

[Tom Elliott]

@Sebastian-Roth what about staying true to fog project itself? How about username fogproject?

As most users seem to use fog for our normal stuff I think this would be descriptive enough for admins to know who and why it was created and limit the number of issues with just plain fog

[Sebastian Roth]

@Tom-Elliott Yeah, kind of like that idea. I will still add the account locking mechanisms mentioned below.

@george1421 Comments?

[george1421]

@Sebastian-Roth said in Circumnavigate fog user issues:

Comments?

I’m good with anything as long as we move off fog as the service name to avoid confusion with the web ui account as well as the bad instructions that say to install FOG as the fog linux user.

[Sebastian Roth]

@george1421 @Tom-Elliott I think I have put this off for way too long as I expected it to be complicated to handle in all cases (fresh install as well as updates). But seems like this is fairly easy to accomplish: https://github.com/FOGProject/fogproject/compare/dev-branch...rename-account

It’s still not finished yet but the basis is done and locking down the account won’t be much work I hope as I have done all the research and testing before.

Highly appreciate any comments you guys have on this. I have greped the whole code to make sure I don’t miss anywhere to change the name or handle the new name.