remove write

[A. Jorge Garcia]

I have to remove write from my knoppix-installered LAN. My students recently discovered write and are passing notes during class....

How do I remove it or turn it off. In older version of KNOPPIX it was off and root had to trun it on. BTW, I'm using KNOPPIX 3.9 on these PCs.

Regards,
AJG

[UnderScore]

I haven't tested this, but you can make it owned by root user & root group.

ls -l `which write`
chown root.root `which write`

Then remove other read, write & execute permissisons.

chmod o-rwx `which write`

That should do it.

[A. Jorge Garcia]

OK, here's what I got:

root@CentauriPrime:~# which write
/usr/bin/write
root@CentauriPrime:~# ls -l /usr/bin/write
lrwxrwxrwx  1 root root 23 May 11 12:54 /usr/bin/write -> /etc/alternatives/write
root@CentauriPrime:~# ls -l /etc/alternatives/write
lrwxrwxrwx  1 root root 18 May 11 12:52 /etc/alternatives/write -> /usr/bin/bsd-write
root@CentauriPrime:~# ls -l /usr/bin/bsd-write
-rwxr-sr-x  1 root tty 7992 Nov  1  2004 /usr/bin/bsd-write
root@CentauriPrime:~#

Wow, look at all those symbolic links! So, root already owns write, do I just limit the permissions on /usr/bin/bsd-write?

In other words, as root, I don't have to

chown root.root /usr/bin/bsd-write

but, as root, I do have to

chmod o-rwx /usr/bin/bsd-write

BTW, as root, isn't this the same as:

chmod 700 /usr/bin/bsd-write

BTW, what does -rwxr-sr-x mean?

TIA,
AJG

[UnderScore]

In other words, as root, I don't have to

chown root.root /usr/bin/bsd-write

but, as root, I do have to

chmod o-rwx /usr/bin/bsd-write

BTW, as root, isn't this the same as:

chmod 700 /usr/bin/bsd-write

Not really. I intended to use o-rwx so that other (anyone not root) could not even run or copy the write binary. -rwxrwxrwx is 777. So a o-rwx would make it -rwxrwx---. A 700 would make it -rwx------ so that members of root group other than the root user could not access the write binary.

BTW, what does -rwxr-sr-x mean?

The set GUID bit.

http://www.zzee.com/solutions/unix-p..._14_1077830297

SGID If set, then replaces "x" in the group permissions to "s", if group has execute permissions, or to "S" otherwise. Examples:
-rwxrws--- both group execute and SGID are set
-rwxr-S--- SGID is set, but group execute is not set

http://www.puschitz.com/SecuringLinux.shtml

SUID/SGID Files

When the SUID (set user ID) or SGID (set group ID) bits are set on an executable, it executes with the UID or GID of the owner of the executable rather than that of the person executing it. This means that e.g. all executables that have the SUID bit set and are owned by root are executed with the UID of root. A good example is the passwd command that allows ordinary users to update the password field in the /etc/shadow file which is owned by root.

But SUID/SGID bits can be misused when the SUID/SGID executable has a security hole. Therefore, you might want to search the entire system for SUID/SGID executables and document it. For example, ensure that code developers don't set SUID/SGID bits on their programs if it's not an absolute requirement. Very often you can use workarounds like removing just the executable bit for world/others. However, a better approach is to change the design of the software if possible.

To search the entire system for SUID or SGID files, you can run the following command:

find / -path /proc -prune -o -type f -perm +6000 -ls

The -prune option in this example is used to skip the /proc filesystem.

http://www.experts-exchange.com/Secu..._21398469.html

There are times when setuid/setgid is either necessary or useful for a program. E.g. if you want a user to be able to access a CD-Recorder device thru software that has built-in access restrictions; the device needs to be accessed as root, but you don't want to give the user root access. IF the software is specifically designed to be operated setuid root, then this should be safe. sudo is an excellent utility, but some software just needs elevated privileges to function properly, and use of sudo should not be generically required or considered a replacement for setuid/setgid.

Directories that have the sticky bit set are to assign proper permissions to files automatically. Removing the sticky bit on directories will not improve security. It can be a good idea to remove setuid/setgid bits from programs which you know will not need to be run by non-root users on a server, or where you wish to restrict it to specific users via sudo... this is advantageous to security ONLY on the presumption that there may in fact be security flaws in these programs that could be exploited in the future. The same argument serves for disabling services which are not needed.

[A. Jorge Garcia]

Wow, this permissions stuff and all these links are getting complicated!

OK, so all I have to do, as root, is:

chown root.root /usr/bin/bsd-write
chmod o-rwx /usr/bin/bsd-write

right?

I'm sorry to be so obtuse about this, but this is my school server and I'm not too familiar with the proceedure you suggest, so I'm being extra careful not to muck it all up....

Thanx,
AJG

[UnderScore]

I would not do this

chown root.root /usr/bin/bsd-write

and instead just do this

chmod o-rwx /usr/bin/bsd-write

Then open up two terminal windows. In each become a student.

su - student1
su - student2

Then try to use the write program. If it fails, then obviously there is nothing left to do. If it still works, then perhaps more permissions need to be reduced.

[A. Jorge Garcia]

OK, I logged-in to my school sever from home (sick day today) via ssh as root as follows:

root@CentauriPrime:~# chmod o-rwx /usr/bin/bsd-write
root@CentauriPrime:~# write
usage: write user [tty]

and then as me (Mr. G) as follows:

mrg@CentauriPrime:~$ write
-bash: /usr/bin/write: Permission denied

so it would seem that we have been successful!

Thanx again, James, for all your guidance!

Regards,
AJG