scp root-owned files with ssh "PermitRootLogin no"

[Johan Vinke]

For security reasons, our company runs a security-scanning package called BladeLogic. It uses version 1.3.1 of the CIS guidelines. (Center for Internet Security, HPUX Benchmark v1.3.1) Rule 1.3 states install ssh and set this parameter in the sshd_config file: PermitRootLogin no . But if we comply with the BladeLogic / CIS rule, then we cannot copy root-owned files to other systems _AND_ save the permissions/date/timestamp on the files. (We use scp -p extensively.) Is there another tool/method/procedure to do this? We need to copy (both push and pull) root-owned files across systems, and we need to have the permissions/date/timestamps preserved. Also, depending on the permissions of the source or target directory, some non-root users will not be able to read/search the source or write to the target.

[Jeff_Traigle]

We get around this by setting "PermitRootLogin without-password". This allows the use of keys while disallowing interactive root logins.

[Johan Vinke]

Thank you Jeff for your very prompt reply.

If the sshd_config file has this:

PermitRootLogin without-password

I don't think it will pass the BladeLogic scan. The scan looks for this line explicitly:

PermitRootLogin no

And I doubt you can put both lines into the sshd_config file. :-( But then, I haven't tried that yet.

[Matti_Kurkela]

I think you've got the wrong end of the stick.

You're running some application(s) as root, aren't you?

*That* is the problem you should be fixing. Security guidelines and scanners are not too good at judging this directly, so they are set up to flag some of the common tell-tales and bad practices that are caused by this.

If your security fundamentals are OK, you won't need workarounds to comply with the security rules: the compliance comes as a side effect of following the

Many applications that use a TCP/UDP port < 1024 and therefore must be started as root have a mechanism which allows the application to switch into another user after claiming the port. If your application has this mechanism, *use it*.

You should also be using groups to minimize the need to care about which _user_ owns which file. Another useful tool is the setgid bit on directories, which sets the group of any new files/directories created within that directory to match the group of the directory, and not the primary group of the creating user (as usual). If a new sub-directory is created, the setgid bit is also automatically inherited by the sub-directory.
(This may not work for root, so it may actually be *easier* to just set up the top directory of the application data tree as a root and then use a non-root account with the proper group membership to create the rest.)

This is much easier to do in the planning stage, when the application has not been installed yet; but it's usually do-able later too, although often much harder.

Some basic rules:

- The application must ultimately run as a non-root user that belongs to the group that owns the application data directories, and be started with an umask value that allows group write access.
(e.g. user appuser, primary group appdata, umask 002 or 007 as appropriate)

Access to this user account should be governed by sudo or equivalent, so that nobody needs to know the password for this account. In fact, the account can be completely "deactivated" in the user management point-of-view if system services like cron jobs are not needed on the application account.

If the application needs to start as root to access a low-numbered network port, this is what it should be configured to switch itself to after claiming the port. If the application cannot be configured to switch, this set-up will still work if the application is started up with one of the specified umask values.

- The application data directories must be writeable by the group that owns the application data, group writeable and setgid
(e.g. user *not important*, group appdata, chmod 2775 or 2770 as appropriate)

- The users authorized to use the application should be members of the group that owns the application binaries, and should use an umask that allows group writes
(user joe, list of groups includes appdata, umask 002 or 007 as appropriate by the overall security set-up of the system)

If a traditional HP-UX group assignment policy is used, your users will need to learn to use the umask command, and the admin needs occasionally fix the permissions when the user forgot to use the correct umask and cannot be made to fix it him/herself (on vacation/sick/unreachable).

However, if you use a trick common in various Linux distributions and allocate each user a primary group of his/her own (e.g. user "joe", primary group "joe", and nobody else belongs to the group "joe"), the users' default umask can always allow group writes without undermining the security of their home directories.

In this case, the users will have to pay attention to the permissions of any optional access control files in their directory (.rhosts, .ssh key directory etc.). In many cases, the system will not honor these files if their permissions are not set correctly anyway, so this should not be too big a burden.

- If the administration of this application needs to be delegated to someone with no full sysadmin access, it can be done: just make another group that will own the application's binary and configuration files and the directories they're in.

Generally, the user account that runs the application does *not* need to be a member of this group.
(example permissions for application binaries etc.: owner *whoever*, group appadmin, group write permission enabled, other permissions as required by the application)

If the application is installed by swinstall, there is generally no way to delegate full application admin access without allowing the app-admin a way to become root. This just means the sysadmin must always be involved in application upgrades, which is a good policy anyway (the sysadmin should be able to understand the permissions scheme and fix it if the upgrade does something dumb).

MK

[Matti_Kurkela]

Oops, I left an incomplete sentence near the beginning of the previous wall-of-text:


If your security fundamentals are OK, you won't need workarounds to comply with the security rules: the compliance comes as a side effect of following the _good security practices_.

MK

[Johan Vinke]

Thank you Matti for your very comprehensive reply.

> You're running some application(s) as root, aren't you?

The only things we do as root are SysAdmin related tasks. (SAM, editing other config files, ...) And we are in the process of installing sudo and converting to the use of sudo for standard SysAdmin tasks.

But the key function/capability I was referring to is:

scp (copying root-owned files across systems)

> You should also be using groups to minimize the need to care about which _user_ owns which file.

True for some files. But patches, software depots, some config files, other system files _must_ be owned by root:sys or root:root or bin:bin. Even the BladeLogic scan that we use will cause a non-Compliance flag to be raised if certain files do not have the correct ownership or __permission__!! (It's almost like these BladeLogic folks don't know the hoops we will have to jump through to comply with their rules.)

So I could make some of these files not owned by root (or bin). But then, some things would not work and what's worse, the BladeLogic scan would report non-compliance!!

I appreciate all the words of wisdom in your post. But the key point remains:

How can I copy root-owned files across systems maintaining ownership/permissions/date-timestamps if root cannot use ssh/scp?

This is not a requirement for some application; rather this is required for SysAdmin functions.

Thanks again.

[Jeff_Traigle]

Security is a set of policies that each organization must define for themselves. You can't blindly try to make any particular auditing tool happy on every point without considering your own organization's requirements. If your local policy states it's necessary and allowable to copy files as root via scp, then my method will work to limit the access to using keys and bring you closer to compliance with the CIS guidelines since not just anyone from anywhere can login as root directly via SSH... they must have access to the private key and use that.

[Matti_Kurkela · Accepted solution]

I see.

I don't know BladeLogic specifically, but unless it's been specifically tailored for the requirements of your application environment, the results may require some interpretation. Some things flagged as having security impact may be justified if they're the result of careful planning and their security impact has been minimized in some other way (documenting your set-up helps a lot here). Sadly, some management types don't understand this.

This would apply to setting sshd's PermitRootLogin to "without-passwd" vs. "no". Unfortunately "PermitRootLogin=without-passwd" sounds scary if the reader does not know what it actually does, so the justification document must make this absolutely crystal clear and probably refer to SSH documentation on docs.hp.com for further proof.

In general, you cannot create files owned by root unless you actually are root - and that is as it should be. If Joe User has the ability to create files owned by root, that opens a huge can of worms security-wise.

But for admin-related use, for users that have root privileges anyway, it may not be such a big deal.

In HP-UX, the /etc/privgroup file can be used to allow non-root users to use chown() system calls, enabling any programs that already have the functionality to change file ownerships to do so even when running as a non-root user.

Add to /etc/privgroup a line:

CHOWN

Then run "setprivgrp -f /etc/privgroup".
Logout and login to make sure the change is effective in your session. You can use the "getprivgrp" command to verify that the chown privilege is in effect.

See "man 1m setprivgrp" for details:

http://docs.hp.com/en/B2355-60130/setprivgrp.1M.html

If BladeLogic's security scan is any good in detecting HP-UX-specific points of vulnerability, I would expect it to flag the /etc/privgroup file too. In that case, the "documented justification for different settings" is the way to go.

MK