Hi, All!!!
Will you so kind to tell me how I can organize the whitelist of trusted USB devices and all of other USB shouldn’t recognized?
I suppose, that I should write some udev rules but my experience too small!
Many thanks!
Hi, All!!!
Will you so kind to tell me how I can organize the whitelist of trusted USB devices and all of other USB shouldn’t recognized?
I suppose, that I should write some udev rules but my experience too small!
Many thanks!
VBY wrote:
> Hi, All!!!
>
> Will you so kind to tell me how I can organize the whitelist of trusted
> USB devices and all of other USB shouldn’t recognized?
> I suppose, that I should write some udev rules but my experience too
> small!
if you don’t exercise physical security of your hardware you have no
security…so, no matter how well you block non-trusted USB devices
with udev rules (or whatever) if a black hat has the physical access
necessary to plug_in a rogue device s/he can just as easily boot
from a CD, and run programs in RAM allowing it to bypass your
“whitelist” and all other safeguards you have installed…
its like locking the door and leaving all the Windows open, wide.
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
Thanks for reolay!
I know it. This action is considered as a complement to existing security.
I haven’t got any CD-ROM and floppy drives. Only USB ports, that I i’d like to restrict.
Any other idea?
VBY wrote:
> I haven’t got any CD-ROM and floppy drives. Only USB ports, that I i’d
> like to restrict.
> Any other idea?
i can’t do it for you because i do not know how, and i do not easily
find a how-two other than that in man/info udev…i can only suppose
you have been through those and seek something more (?)
…all i could do is what you can do for yourself: use google to
track down the how to…might begin with a search like: udev whitelist
trusted USB devices
just openSUSE:
http://www.google.com/search?q=site%3Aopensuse.org+udev+whitelist+trusted+USB+devices
Linux wide:
http://www.google.com/search?q=linux+udev+whitelist+trusted+USB+devices
then wiggle the search terms until your answer pops out…
alternatively, you might seek an answer on an openSUSE mail list
(where the more technical superstars hang):
http://en.opensuse.org/Communicate#Mailing_Lists
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
For writing udev rules I think this is a good starter: Writing udev rules
But like DenverD imho you should try to concentrate on what you want to achieve. If you want to block storage devices on your running openSUSE system, then you can most probably do that with udev rules. But I think that is not what you really want. And when you want to block people reading/writing from external to internal and vv. there is much more than a smple blocking of those storage devices. They could even unscrew the box, take the disk out and do anything with it on another place ;). How far does one want to go with protection?
On 2010-07-07 18:16 GMT hcvv wrote:
>
> For writing udev rules I think this is a good starter: ‘Writing udev
> rules’ (http://reactivated.net/writing_udev_rules.html)
>
> But like DenverD imho you should try to concentrate on what you want
> to achieve. If you want to block storage devices on your running
> openSUSE system, then you can most probably do that with udev rules.
> But I think that is not what you really want. And when you want to
> block people reading/writing from external to internal and vv. there
> is much more than a smple blocking of those storage devices. They
> could even unscrew the box, take the disk out and do anything with it
> on another place ;). How far does one want to go with protection?
In those cases, the case has theft protections. It can be the simple
bios detecting a switch in the case, or an alarm via wire loop through
the case, with a bell on the room where the chap with gun sleeps. Or,
sensitive data is stored in a network server, to which you have not
access if you don’t boot the in-house operating system.
There can be many things. I’m not a security expert, nor sufficiently
paranoid. Someone here mentioned removing the kernel module for use
storage, but then you also have to control that no one adds that module
in any way…
I would also investigate apparmour. Two years ago it couldn’t do this,
but perhaps now it can. No idea. Another thing to investigate would be
access lists (ACL).
Mmm… now that I think, I know someone that disables the USB bus
completely, in bios and hardware. Now I know why the use Keyboard and
mouse via ps/2 plugs
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Elessar))
On 07/07/2010 06:06 PM, Carlos E. R. wrote:
> I would also investigate apparmour. Two years ago it couldn’t do this,
> but perhaps now it can. No idea. Another thing to investigate would be
> access lists (ACL).
Not Apparmor, but SELinux. This situation is exactly why the National
Security Agency developed the code. One would not want a user of a secure
computer being able to copy the data onto a USB stick. SELinux is a pain
to set up and alswo one to use, but it will do the job.
Larry Finger wrote:
> On 07/07/2010 06:06 PM, Carlos E. R. wrote:
>> I would also investigate apparmour. Two years ago it couldn’t do
>> this, but perhaps now it can. No idea. Another thing to investigate
>> would be access lists (ACL).
>
> Not Apparmor, but SELinux. This situation is exactly why the National
> Security Agency developed the code. One would not want a user of a
> secure computer being able to copy the data onto a USB stick.
Probably not important, but apparmor will certainly help you prevent
that too.
–
Per Jessen, Zürich (17.8°C)
http://en.opensuse.org/User:Pjessen
sure is nice to have more folks around who know and don’t just guess
(like me)…
thank you!!
–
DenverD (Linux Counter 282315)
CAVEAT: http://is.gd/bpoMD
via NNTP w/TBird 2.0.0.23 | KDE 3.5.7 | openSUSE 10.3
2.6.22.19-0.4-default SMP i686
AMD Athlon 1 GB RAM | GeForce FX 5500 | ASRock K8Upgrade-760GX |
CMedia 9761 AC’97 Audio
On 2010-07-08 05:52 GMT Per Jessen wrote:
> Larry Finger wrote:
>
> > On 07/07/2010 06:06 PM, Carlos E. R. wrote:
> >> I would also investigate apparmour. Two years ago it couldn’t do
> >> this, but perhaps now it can. No idea. Another thing to investigate
> >> would be access lists (ACL).
> >
> > Not Apparmor, but SELinux. This situation is exactly why the
> > National Security Agency developed the code. One would not want a
> > user of a secure computer being able to copy the data onto a USB
> > stick.
>
> Probably not important, but apparmor will certainly help you prevent
> that too.
How could it be done? I’m interested.
I know how to make a profile for preventing a program from accessing
files, and that access to devices was being thought about. But the
profile is only for one program, not for all. Have they added this
possibility?
Since the dev was fired from Novell they keep silent about it, Yast
doesn’t have new AA modules.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” GM (Minas Tirith))