LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Linux - Security (https://www.linuxquestions.org/questions/linux-security-4/)
-   -   Blocking external usb storage access on centos 5 (https://www.linuxquestions.org/questions/linux-security-4/blocking-external-usb-storage-access-on-centos-5-a-644221/)

pradeep.oops 05-23-2008 02:24 AM

Blocking external usb storage access on centos 5
 
HI,

This is my first post thread .I want to block external usb storage completly on my server running on centos 5 having confidiential data.

For that i used udev and blocked the external usb storage by creating the udev rule mentioning any usb storage will get mounted to /dev/null so that users cant mount as well.

But in the mean time i am getting below log in my /var/log/messages file when i insert any usb storage device.

######################################################
May 23 12:24:02 localhost kernel: usb 1-4: new high speed USB device using ehci_hcd and address 4
May 23 12:24:02 localhost kernel: usb 1-4: configuration #1 chosen from 1 choice
May 23 12:24:02 localhost kernel: scsi3 : SCSI emulation for USB Mass Storage devices
May 23 12:24:07 localhost kernel: scsi 3:0:0:0: Direct-Access USB Flash Disk 1100 PQ: 0 ANSI: 0 CCS
May 23 12:24:07 localhost kernel: sd 3:0:0:0: [sdb] 1981440 512-byte hardware sectors (1014 MB)
May 23 12:24:07 localhost kernel: sd 3:0:0:0: [sdb] Write Protect is off
May 23 12:24:07 localhost kernel: sd 3:0:0:0: [sdb] Assuming drive cache: write through
May 23 12:24:07 localhost kernel: sd 3:0:0:0: [sdb] 1981440 512-byte hardware sectors (1014 MB)
May 23 12:24:07 localhost kernel: sd 3:0:0:0: [sdb] Write Protect is off
May 23 12:24:07 localhost kernel: sd 3:0:0:0: [sdb] Assuming drive cache: write through
May 23 12:24:07 localhost kernel: sdb: sdb1
May 23 12:24:07 localhost kernel: sd 3:0:0:0: [sdb] Attached SCSI removable disk
May 23 12:24:07 localhost kernel: sd 3:0:0:0: Attached scsi generic sg2 type 0
##############################################

I want to know how device name sdb1[see above log] was created and who is creating kernel or udev and is it possible to block the device node creation,if so wht i can do to block the same in my messages log.


Regards
lingu

born4linux 05-23-2008 04:42 AM

you can try creating a udev rule in your system for this. in
centos5, you can create it as:

/etc/udev/rules.d/10-local.rules

# the rules in /etc/udev/rules.d are parsed lexically
# so the prefix 10 should make the rule override the defaults:

and put something like:

KERNEL=="sdb", MODE="0000"

which will give the mode 0000 (no access) to sdb

Or, just for the fun of it:

KERNEL=="sdb", RUN+="/usr/bin/script_to_trash_the_device.sh"

check the man page for udev for info.

hth.

unSpawn 05-23-2008 05:47 AM

hello and welcome to LQ, hope you like it here.


Quote:

Originally Posted by pradeep.oops (Post 3162153)
I want to block external usb storage completly on my server running on centos 5 having confidential data.

Four questions if you don't mind. What level of confidentiality are you talking about? Does it require people to be subject to screening before working with the machine? Only work supervised? Be searched? What purpose does the machine have? Is it a headless server or a workstation? How can information be transferred in other ways? Send information over the network? Make a screenshot? Have you set up SELinux for compartmentalisation of information?


Quote:

Originally Posted by pradeep.oops (Post 3162153)
For that i used udev and blocked the external usb storage by creating the udev rule mentioning any usb storage will get mounted to /dev/null so that users cant mount as well.

Please post the exact steps how you did that?


Quote:

Originally Posted by pradeep.oops (Post 3162153)
I want to know how device name sdb1[see above log] was created and who is creating kernel or udev and is it possible to block the device node creation,if so wht i can do to block the same in my messages log.

AFAIK and generally speaking device detection is *always* and firstly a kernel task, it provides subsystems with triggers to act on. IMHO the first thing would be to recompile the kernel, leaving out functionality that could lead to information security risks, before implementing other restrictions.


All times are GMT -5. The time now is 03:41 PM.