BookmarkSubscribeRSS Feed
🔒 This topic is solved and locked. Need further help from the community? Please sign in and ask a new question.
kevind
Obsidian | Level 7

For OS administration of your SAS servers and your user's folders and files, do you:

A.  Have direct root access.

B.  Have 'sudo -u root' access with unrestricted commands as root.

C.  Have 'sudo -u root' access with limited commands as root

D. none of the above

E. Some other tools or methods.   If so, what?

Just wondering.   My access has gone from option A to D and now I'm in the process of getting approval for option C.

1 ACCEPTED SOLUTION

Accepted Solutions
jakarman
Barite | Level 11

The chown will be not granted by running by root as you could define an ownership of root to an executable and with chmod setting the setuid bit. At that moment you can gain unmonitored system access

More applicable wull be: "sudo -u (account) *  " by wich you can swich to that "high priviledged account"  eg the installation key needed when applying a fix.

The chgrp and all other commands can be run using a "high priviledged account" that is bound to a specific role.

Running those commands in the key-0 mode (root) I exepect the security admins are wanting a fully specified command with directories/filenames

Setting  the setuid bit and ownership of those special files (installation doc) as requirement would be a good case.

Viewing group user information  (lsgroup lsuser id) is also very applicable to be run at root level.

You will see the information needed for problem analyses in that area.

The joke is that with SAS you can bypass "sudo -u account" as that is the functionality by sasauth saselsrv sasspwn.

The only requirement is needing the password of a related account. I they block that (sassrv STP) that functionality stops 

---->-- ja karman --<-----

View solution in original post

17 REPLIES 17
jakarman
Barite | Level 11

Kevind,  The normal professional approach of using Unix/Linux is not to use root but as quickly abandon that and using at least sudo.

As you do not need a full system access, as the system often is delivered as a service, the limitation to restrict that is quite common for professional supported systems.

Sometimes alternative instead of sudo are used, but the logical approach as described still as a valid one holding.

All is a result of more high level mandatory guidelines. These are not well mentioned or even being aware at SAS.   

---->-- ja karman --<-----
kevind
Obsidian | Level 7

So with sudo, the question security will want to know is which Unix/Linux commands are needed by the SAS Admin.   What comes to mind is rm, chmod, chgrp, chown, ln, ls, mv, cp, stat, tar, find, kill, cat.   Are there any other commands that you can think of?

Kurt_Bremser
Super User

Since I am both the system admin and the SAS admin, I have complete root access (I also do system installation&maintenance). But I keep my "hats" strictly separated:

root - users, file systems, access rights etc

sas - SAS installation&maintenance

my personal id - SAS development

ctrl-m user - manual runs of SAS batch jobs

tommy81
Obsidian | Level 7

Hi  Kurt,

 

Would it be wise to setup only 2 AD groups in Linux ,one for all SAS users another for Admins .

What folders shoud be restricted to the business users ,even though they will only have read only access ? 

Kurt_Bremser
Super User

@tommy81 wrote:

Hi  Kurt,

 

Would it be wise to setup only 2 AD groups in Linux ,one for all SAS users another for Admins .

What folders shoud be restricted to the business users ,even though they will only have read only access ? 


That is solely yours to decide, depending on the needs. The sasadmin group on our server has rwx permissions on all data directories (per access control lists), while non-admin users are members of groups according to the business needs. Data folders belong to one of the groups, so access can be controlled by the groups a user is assigned to.

The user groups number in the range of ~50.

jakarman
Barite | Level 11

The chown will be not granted by running by root as you could define an ownership of root to an executable and with chmod setting the setuid bit. At that moment you can gain unmonitored system access

More applicable wull be: "sudo -u (account) *  " by wich you can swich to that "high priviledged account"  eg the installation key needed when applying a fix.

The chgrp and all other commands can be run using a "high priviledged account" that is bound to a specific role.

Running those commands in the key-0 mode (root) I exepect the security admins are wanting a fully specified command with directories/filenames

Setting  the setuid bit and ownership of those special files (installation doc) as requirement would be a good case.

Viewing group user information  (lsgroup lsuser id) is also very applicable to be run at root level.

You will see the information needed for problem analyses in that area.

The joke is that with SAS you can bypass "sudo -u account" as that is the functionality by sasauth saselsrv sasspwn.

The only requirement is needing the password of a related account. I they block that (sassrv STP) that functionality stops 

---->-- ja karman --<-----
jakarman
Barite | Level 11

Kurt your attitude is one of good professional, keep your "hats" strictly separated.
As the business your are in is very small, there are is sensitive data involved, you are the one being responsible accountable (consulted/informed) all in one this is a good approach.

But suppose:

- you are in some bigger organization with those technical hats being segregated

- there are some legal aspects in the sensitivity of the data, by that needing a segregation on duties (operations/development/monitoring).

You get into those challenges that the requestor with these question did.

Often you are in a situation that the SAS approach does not follow all the requirements by mandatory policies at the technical level. With that you have bad or no acceptance top be part of IT. 

---->-- ja karman --<-----
BStone
Obsidian | Level 7

Interesting topic.

I know it's a few months old, but I will try and keep the momento going on this topic Smiley Happy

Firstly, I like the methodology you use KurtBremser, but as Jaap mentioned, in a larger organization there are many things to consider. Due to these considerations, things could become more complicated if you implement a multi tier SAS platform with third party software, i.e. Platform Suite for SAS (Grid) which requires root access!

I would like to know what other SAS Administrator / Installers do in this case? As kevind's original post, what method are you likely to use when deploying SAS in a large organization with limited / no root access?

A.  Have direct root access. Mostly likely it will NOTbe possible to provide root access due to oganizational policies

B.  Have 'sudo -u root' access with unrestricted commands as root. To an extend based on the client and the company size

C.  Have 'sudo -u root' access with limited commands as root. Yes, this is generally the best method I've used in my deployments

D.  None of the above. :smileyconfused:

E.  Some other tools or methods.   If so, what? Working together with dedicated resources in the Unix, Security and Active Directory teams, this generally takes longer to deploy the software based on the resource's knowledge of SAS, OS commands, other projects, etc.

JuanS_OCS
Amethyst | Level 16

Interesting topic, indeed.

Do you have any suggestion or papers for specific SAS administration requirements on the limited sudo configuration for the sas-admin user?

Kurt_Bremser
Super User

I actually would avoid giving the "sas" user (the SAS admin) sudo rights.

Because this userid will run a lot of the server processes; have one weakness there, and the sudo will allow a big privilege escalation.

Instead the group of sas admins should have the sudo option for "sas", so they can change over to do install maintenance.

root must have set up the filesystem so that "sas" does not need any advanced permissions to do its job.

BStone
Obsidian | Level 7

I would not give sudo access to the "sas-admin" user / "SAS Installer", but only to a normal user or group. Keep the SAS external accounts separate from your super users / sudoers file.

If you going down the root of using sudo access, rather do it for a user or admin group.

In terms of SAS papers, I have never come across any published papers, I guess many admin/installers keep their own material since deployments are hardly the same from site to site. A normal one machine deployment would not require many tasks for the root user, but a multi-tier deployment and business system integration like databases, SSO, etc. may require root access to carry out a multitude of tasks - these generally fall outside of SAS and should be working outside of SAS first, i.e. SSO must be working outside of SAS first.

Maybe we can start a new discussion and list all tasks required by external users???

JuanS_OCS
Amethyst | Level 16

I think that is a great initiative to create a new discussion about this, specific and very useful. So if there is no related paper, maybe it is also a good idea for a paper  Smiley Happy

I did the distinction of "sas-admin" as an example and intention of describe that it should be different than the sasinst/sas/etc (aka SAS installer)

jakarman
Barite | Level 11

It is interesting as common practices at SAS is violating those common guidelines at the OS level. (very ugly situation).

It are the hardening of an OS papers were this is coming from. Regulations are directing to those same kind of papers.

Your options:

A/ you will locked in some broom cabinet. As soon as possible that environment will be dumped.

    It can look a success having a server machine under your desktop. That is the short limited time vision.

B,C/ sudo (root is Implied) is very limited allowed in an isolated INFRA-Develop environment.

    The sudo with root for some limited commands is needed for setting setuid rights on some limited number of files. (3 files in SAS, and some of the same count in LSF).

    Those are needed for the same core functionality as other more well known daemons for a Unix guy.

    There should be a document by SAS (IBM-LSF) explaining that functionality and that is not malware (no it is not there).

D,E/ Us a installation key (high privileged system key) for the deployment using sudo.

    Sudo README File http://www.courtesan.com/sudo/intro.html is associated for root but is suitable for every high privileged system key.  the -u user option Sudo Manual

    As it rather easy to design all functionality to associated system keys you can set up several of those where segregation is needed.

    As goal all loadables owned by the installation key. That is the only usage for that key.  An other for maintaining the configuration files etc.....

    Using this approach you will get a compliant installation (regulations policies).

When it has been build in INFRA-develop the release process is started to get this into supported environments by the business.

Those environments can have a business Dev/Tst/Acpt/Prod with possible combinations on some limited machines (getting it workable).

This process is needing to follow the applicable ICT policies for that (rpm or others) where the use of a SAS software depot and SDW is not wanted/allowed.  

---->-- ja karman --<-----
AmineBs
Calcite | Level 5

Hi All, Intersting post. What if securtiy policy is prohibiting the setuid required for the auth files needed by SAS ? is there any other option to get the 3 modules running fine : sasauth, sasperm and elssrv ?

suga badge.PNGThe SAS Users Group for Administrators (SUGA) is open to all SAS administrators and architects who install, update, manage or maintain a SAS deployment. 

Join SUGA 

CLI in SAS Viya

Learn how to install the SAS Viya CLI and a few commands you may find useful in this video by SAS’ Darrell Barton.

Find more tutorials on the SAS Users YouTube channel.

Discussion stats
  • 17 replies
  • 5651 views
  • 2 likes
  • 7 in conversation