[Help!] I don't want NIS+ user to use "niscat passwd.org_dir" to look at......

Hanzo · 07-30-2008, 07:50 AM

NIS+ OS: opensolaris 2008.05 as NIS+ Server IP: 192.168.80.202
NIS+ OS: opensolaris 2008.05 as NIS+ Client IP: 192.168.80.38

Now：at NIS+ Server,I have 2 users, one is user1 and the other is user2，
Purpose I wanna implement：After ssh the NIS+ client, I don't want user1 or user2 to use the command "niscat passwd.org_dir" to look at any conments of file "passwd.org_dir". Or user1 can't look at the encrypted information of passwd.org_dir.

Can anyone tell me how to implement that?

Code:

ssh  user1@192.168.80.38

Code:

niscat passwd.org_dir

Code:

root:*NP*:0:0::/root:/usr/bin/bash:*NP*
............................................
user1:PUHF95SxdLvFo:60005:60005:users:/export/home/user1:/bin/bash:
user2:s0gTFTxXgp7fA:60006:60006:users:/export/hoome/user2:/bin/bash:

use keylogout,"niscat passwd.org_dir"：

Code:

user1:*NP*:60005:60005:users:/export/home/user1:/bin/bash:*NP*
user2:*NP*:60006:60006:users:/export/hoome/user2:/bin/bash:*NP*

I wanna implement this：type the "niscat passwd.org_dir" after using the command "keylogin"：

Code:

user1:PUHF95SxdLvFo:60005:60005:users:/export/home/user1:/bin/bash:
user2:*NP*:60006:60006:users:/export/hoome/user2:/bin/bash:*NP*

Or

Code:

user1:*NP*:60005:60005:users:/export/home/user1:/bin/bash:
user2:*NP*:60006:60006:users:/export/hoome/user2:/bin/bash:*NP*

I do removed the relative rights, but it still doesn't work.

Code:

niscat -o passwd.org_dir

Code:

Object Name   : "passwd"
Directory     : "org_dir.ds.org."
Owner         : "dsbj-tm10.ds.org."
Group         : "admin.ds.org."
Access Rights : ----------------
Time to Live  : 12:0:0
Creation Time : Wed Jul 30 09:38:44 2008
Mod. Time     : Wed Jul 30 17:10:28 2008
Object Type   : TABLE
Table Type          : passwd_tbl
Number of Columns   : 8
Character Separator : :
Search Path         :
Columns             :
        [0]     Name          : name
                Attributes    : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE)
                Access Rights : r---r---r---r---
        [1]     Name          : passwd
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------
        [2]     Name          : uid
                Attributes    : (SEARCHABLE, TEXTUAL DATA, CASE SENSITIVE)
                Access Rights : r---r---r---r---
        [3]     Name          : gid
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---r---r---r---
        [4]     Name          : gcos
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---rmcdrmcdr---
        [5]     Name          : home
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---r---rmcdr---
        [6]     Name          : shell
                Attributes    : (TEXTUAL DATA)
                Access Rights : r---rmcdrmcdr---
        [7]     Name          : shadow
                Attributes    : (TEXTUAL DATA)
                Access Rights : ----------------

Can anyone figure it out? Thanks!

jlliagre · 07-31-2008, 01:45 AM

Not sure why the NIS+ access rights do not prevent the user password field to be displayed.

You may set an ACL on niscat to remove execution permission to these users, or just remove the execution bit for other.

Please note that NIS+ is deprecated to LDAP as a naming service.

javier.e.menendez · 07-31-2008, 03:12 AM

Hi there:

Have you looked at the nischmod man page? In nis+, you can change the permissions of the table itself or also the permissions of the individual column.

Good luck,

J.

Hanzo · 07-31-2008, 04:25 AM

Quote:

Originally Posted by jlliagre

Not sure why the NIS+ access rights do not prevent the user password field to be displayed.

You may set an ACL on niscat to remove execution permission to these users, or just remove the execution bit for other.

Please note that NIS+ is deprecated to LDAP as a naming service.

I can't remove execution of niscat, cause I want niscat to execute.
I really don't know how to set ACL to limite some rights.

Hanzo · 07-31-2008, 04:27 AM

Quote:

Originally Posted by javier.e.menendez

Hi there:

Have you looked at the nischmod man page? In nis+, you can change the permissions of the table itself or also the permissions of the individual column.

Good luck,

J.

I used nischmod. Please take a look at the results of using "niscat -o passwd.org_dir".

javier.e.menendez · 07-31-2008, 06:22 AM

Hi there:

Can you show a nisls -l passwd.org_dir?

And also, are these users members of the admin group?

jlliagre · 07-31-2008, 07:35 AM

Quote:

Originally Posted by Hanzo

I can't remove execution of niscat, cause I want niscat to execute.

If you want niscat to stay executable for any user, my hack won't work indeed.
Otherwise, if you remove the x flag for other, generic users won't be able to use niscat but root and members of the bin group still will be able to execute it.

Quote:

I really don't know how to set ACL to limite some rights.

Assuming your are using ufs, this command will prevent the "guest" account to run the niscat command.

Code:

setfacl -r -m user:guest:--- /usr/bin/niscat

Consider these permission/acl solution as a weak workaround.

Hanzo · 07-31-2008, 08:43 PM

Quote:

Originally Posted by javier.e.menendez

Hi there:

Can you show a nisls -l passwd.org_dir?

And also, are these users members of the admin group?

Here is the result of typing "nisls -l passwd.org_dir" executed both on NIS+ Server and NIS+ Client.

Code:

T ---------------- dsbj-tm10.ds.org. Wed Jul 30 09:38:44 2008 passwd.org_dir.ds.org.

Hanzo · 07-31-2008, 10:37 PM

Quote:

Originally Posted by jlliagre

If you want niscat to stay executable for any user, my hack won't work indeed.
Otherwise, if you remove the x flag for other, generic users won't be able to use niscat but root and members of the bin group still will be able to execute it.

Assuming your are using ufs, this command will prevent the "guest" account to run the niscat command.

Code:

setfacl -r -m user:guest:--- /usr/bin/niscat

Consider these permission/acl solution as a weak workaround.

I used this command "chmod A5- or chmod A4- ....".
I didn't use this command "setfacl", it doesn't work. I thought we can't remove some rights of niscat,actually should be the file "passwd.org_dir".

Here is the result:

Code:

ls -v /var/nis/data/passwd.org_dir
----------+  1 root     root         176 Jul 30 09:38 /var/nis/data/passwd.org_dir
     0:owner@:execute:deny
     1:group@:read_data/write_data/append_data/execute:deny
     2:everyone@:read_data/write_data/append_data/write_xattr/execute
         /write_attributes/write_acl/write_owner:deny

The user "user1" still can look at the content of passwd.org_dir. It doesn't work.

Buddy, do you have else ideas? Thanks!

jlliagre · 08-01-2008, 02:16 AM

Quote:

Originally Posted by Hanzo

I used this command "chmod A5- or chmod A4- ....".

Huh ?

Quote:

I didn't use this command "setfacl", it doesn't work.

What do you mean it doesn't work ?
What OS are you running ?
What filesystem ?

Quote:

I thought we can't remove some rights of niscat

Why ?

Quote:

Here is the result:

Code:

ls -v /var/nis/data/passwd.org_dir
----------+  1 root     root         176 Jul 30 09:38 /var/nis/data/passwd.org_dir
     0:owner@:execute:deny
     1:group@:read_data/write_data/append_data/execute:deny
     2:everyone@:read_data/write_data/append_data/write_xattr/execute
         /write_attributes/write_acl/write_owner:deny

The user "user1" still can look at the content of passwd.org_dir.

By using cat or niscat ?

Hanzo · 08-01-2008, 03:48 AM

Quote:

Originally Posted by jlliagre

Huh ?
What do you mean it doesn't work ?
What OS are you running ?
What filesystem ?
Why ?
By using cat or niscat ?

OS: OpenSolaris 2008.05.
The Server and client are the same OS.
Absolutely niscat we're talking about.
"it doesn't work" means: the user1 still can look at the encrypted content of the file "passwd.org_dir".

jlliagre · 08-02-2008, 01:41 AM

Okay, I overlook the fact you are using OpenSolaris thus ZFS. As I wrote a couple of times, my syntax was for UFS only.

Here is the corresponding ACL setting for ZFS that prevent the guest account to run netcat::

Code:

chmod A+user:guest:execute:deny /usr/bin/niscat

Alternatively, you can use a group name:

Code:

chmod A+group:groupname:execute:deny /usr/bin/niscat

javier.e.menendez · 08-02-2008, 05:08 AM

Hi Hanzo:

I know that this will start a "flame" war but what the hell, here we go.

If you run nisplus, you fix the permission issues with nisplus commands, NOT with solaris commands. Changing the acls is NOT what you want,
changing the permissions with chmod is NOT what you want.

Let me elaborate on this.

If you take away executable permissions from the command, it affects all the tables and the whole database, not just the passwd table.
That is not what you wanted to begin with.

NIS+ uses a different set of permissions than solaris, you can see this with nisls -l on any directory or table. You have 16 bits of permissions, not the standard 9.

The first four are for nobody, basically anybody that is NOT authenticated with NIS+, you can see if you are with the command nisdefaults.
The next four are for the owner of the table, basically root on the NIS+ root master server.
The next four are for the members of the NIS+ admin group (not to be confused with any group that you may see in /etc/group)
Lastly the next four are for the world, basically users recognized by nis+ but NOT the owner or members of the admin group.

It's 5:30 am here and I am at home, not at work so therefore I don't have a machine running nis+ here. So I am doing this by memory.

The permissions of the table are controlled with nischmod. Like for instance nischmod g-rmcd passwd.org_dir. In this example, I am showing you how to remove read, modify, create and destroy permissions from the group. JUST AN EXAMPLE, DON'T DO IT!

Furthermore, each column of a table (all the tables) has permissions that can be changed. But you already know this. The answer to this is niscat -o passwd.org_dir.
To change the particular permmissions for a column, for example you can type:
nistbladm -u 'name=g+rm,hosts.org_dir'

So if you want to change the permissions for the column, you can do that. However, if both users belong to the same category, both are affected equally by the change. if both users that you created are authenticated by nis+ but they are not root nor members of the admin group, they fall into the category of the "world" (last set of permissions).

You can fix this by putting one of this users into the nis+ admin group. However, now this guy will have a lot more power (look at the general permissions of the admin group in all the tables and columns of the tables.
ex: nisgrpadm -a admin.sun.com. user1.sun.com.

There is a command called nistest that is there for testing specific access rights to an object.

Hope it helps,

J.

Ps: Somebody said in this thread that NIS+ is deprecated. NIS+ is NOT deprecated, it is on its way out for sure but it is still supported by Sun. You can see this when you type nisserver -r -d sun.com. for example. However, that is the same message that you see in solaris 9 and some versions of 8. Lots of Sun customers use it, not as many as they used to of course.

Later,

jlliagre · 08-02-2008, 04:06 PM

Quote:

Originally Posted by javier.e.menendez

If you run nisplus, you fix the permission issues with nisplus commands, NOT with solaris commands. Changing the acls is NOT what you want,
changing the permissions with chmod is NOT what you want.

I absolutely agree. As I wrote, my suggestion to use permissions is just a weak workaround.
Workarounds are IMHO acceptable, especially when security is at stakes, until a proper solution is found and I appreciate your expertise helping finding it.

Quote:

Ps: Somebody said in this thread that NIS+ is deprecated. NIS+ is NOT deprecated, it is on its way out for sure but it is still supported by Sun. You can see this when you type nisserver -r -d sun.com. for example. However, that is the same message that you see in solaris 9 and some versions of 8. Lots of Sun customers use it, not as many as they used to of course.

Being deprecated doesn't means being unsupported but your are correct, NIS+ isn't deprecated yet by Sun. It has been however announced to be "End Of Feature" in 2005 and Sun customers are certainly more than ever encouraged to migrate to LDAP.

http://www.sun.com/software/solaris/faqs/nisplus.xml

Hanzo · 08-03-2008, 09:04 PM

Hi,guys:
I really appreciate your great help!
I don't care whether or not NIS+ is deprecated. I do care how to implement my aim.
Here is the result of executing the command: "nisgrpadm -l admin.ds.org. "

Code:

       #nisgrpadm -l admin.ds.org.
       Group entry for "admin.ds.org." group:
       Explicit members:
        dsbj-tm10.ds.org.
    No implicit members
    No recursive members
    No explicit nonmembers
    No implicit nonmembers
    No recursive nonmembers

I got confused that I can't know whether the user1 or user2 is in the group of admin.ds.org. .
After I executed the commmand

Code:

chmod A+user:user1:execute:deny /usr/bin/niscat

and

Code:

chmod A+group:60005:execute:deny /usr/bin/niscat

(cause the gid of user1 is 60005) and "ssh user1@192.168.80.38", here is result of executing the command " niscat passwd.org_dir":

Code:

       ..............................
       noaccess:*NP*:60002:60002:No Access User:/::*NP*
       nobody4:*NP*:65534:65534:SunOS 4.x NFS Anonymous Access User:/::*NP*
       user1:PUHF95SxdLvFo:60005:60005:users:/export/home/user1:/bin/bash:
       user2:s0gTFTxXgp7fA:60006:60006:users:/export/hoome/user2:/bin/bash:

I think user1 still can look at the contents of passwd.org_dir, is there anything that I didn't do or I should do?