In linux, with Linux built in command, how can I put write/read protection on the sd card ? I will put, with command, protection such as user can not write something on the sd card because I have enabled the only read protection via command.
If you know without command, feel free to share
Anyway with software, you can do only it in a filesytem level. If some one format the pendrive, they will get the permission what ever they want to do on it. If there is something at hardware level for making a sdcard readonly, you will get what you asked here.
Related
I wondered why we need to switch to kernel space when we want to access a hardware device. I understand that sometimes, for specific actions such as memory allocation, we need to make system calls in order to switch from user space to kernel space because the operating system needs to organize everything and make a separation between processes and how they use memory and others. But why we can't directly access a hardware device ?
There is no problem in writing your own driver to access the hardware from User Space and plenty of documentation is available. For example, this tutorial at xatlantis seems to be recent and good source.
The reason it has been designed like that is because mainly due to security reasons .Most systems I know about specifically do not allow user programs to do I/O or to access kernel space memory. Such things would lead to wildly insecure systems, because with access to the kernel a user program could change permissions and get access to any data anywhere in the system, and presumably change it.
References:
XATLANTIS
STACKEXCHANGE
A device-driver may choose to provide access from user processes to device registers, device memory, or both. A common method is a device-specific service connected with an mmap() request. Consider a frame-buffer's on-board memory, and efficiency from a user process being able to r/w that space directly. For devices in general, notably there are security considerations and drivers that provide direct access often set limits to processes with sufficient credentials. Files within /dev are usually set with owner/group access permissions similarly limited.
I want to write a linux inspection tool to check the usb device usage records on a certain machine. Parsing the dmesg method can obtain the usb usage record from the system startup to the present, and does not use dmesg -c to clear the dmesg information. So the point of the question is whether there is a place on the Linux system that records all USB usage records in the system, just like the Windows system writes this in the registry.
Linux doesn't natively provide this functionality. It isn't seen as an intrinsically important feature to have, and as mentioned, it can be done easily with a udev rule for those who want it. It's generally assumed that anyone with physical access to the machine can read any unencrypted data on it and execute arbitrary code on it if it's running, so logging USB devices isn't really an effective security measure.
If you want to see the recent history, you can check the kernel log (often /var/log/kern.log) to read the recent and older entries that the kernel has output when a USB device has been inserted. Do note that these are rotated periodically, so they won't provide the entire history of the system.
We are a hardware vendor and want to provide support for linux.
This means we want to provide a (user space) shared library that can be used by our customers applications without struggling with the lowlevel protocol.
Our Hardware is accessed via USB/HID and thus our library need to get access to /dev/hidrawX.
But to get access to this device (or other kind of hardware devices) it seems that we need to modify the system by adding permissions to the udev system (see
Get access to USB device on Linux (libusb-1.0)?).
Is this really best practice? If so, where should I do this? In the .deb/.rpm/... installer of the customers application? What about FlatPak or similar concepts?
Udev is standard and best practice. Every linux distribution has udev rules files typically for ex in case of ubuntu it is found in /etc/udev/rules.d folder. You need to create a udev rule file and write MODE="0666" rule to it. Take a look at this example for how to write udev rule.
What is the simplest way to export data from a bare-bones OS?
I’m developing some assignments for my Computer Architecture course that require students to time different segments of code as accurately as possible. My idea is to insert the code to be timed right into the "Bare Bones"/"Hello World" tutorial from the OSDev wiki (http://wiki.osdev.org/Bare_Bones), which will effectively run the code under test right inside a minimal OS kernel.
This technique works rather well; but, at the moment, my only output option is the VGA text mode. I would like to be able to save the experiment results so the students can analyze/graph the data.
I’m currently installing the “mini-OS” onto a USB flash drive and booting from the flash drive. My original idea was to use BIOS to dump the experiment data back onto the USB drive; but, it looks like calling BIOS routines from protected mode is non-trivial (i.e., requires switching to real or V86 mode).
All I need to do is dump raw binary data somewhere that another machine can read it. I don't need a file system or anything fancy like that. Is there a relatively simple way to access the USB flash drive (or some other external device), or will I need to find/write a complete USB driver or network driver stack? Or, is there a simpler solution?
This post (Real mode BIOS routine and Protected Mode) mentions PwnOS; but the link to the code is broken.
USB drivers are very hard. However, as you mentioned network drivers, you might want to look into serial ports. They are much easier to program than USB.
The osdev wiki should have enough information about this topic.
I've spent a lot of time developing an operating system and working on my low level boot loader. But now I want to take some time off my operating system while not leaving the low-level environment and doing something involving security.
So I chose to build my own standard password utility following the pre-boot authentication scheme. Since I want the software to be at least a little portable I want it to use as little external support as is possible. I figured that I'd be best if I somehow managed to 'hook' into the bios somewhere between the self checks and the int 19 bootstrap from within a running real mode OS.
However finding information on how to modify the bios code proved to be impossible. I've found nothing on how to achieve the before mentioned. I have only found pages describing how to flash your bios.
Does anyone know how I can read/write bios code? Or can someone provide links to pages that describe this?
I know that it's not only possible to brick my device but it is also likely, I'm aware of the risk and willing to take it.
Pinczakko's articles on BIOS reverse engineering are a great place to start looking at this. There was also a book published by the same author but it is now out of print.
I'm not sure if this approach is the best approach towards a secure boot, but the articles on this site are very detailed and should point you towards a method for modifying your BIOS firmware.
I'm not really sure what you are trying to achieve, but:
The BIOS is completely hardware specific - each manufacturer will have their own mechanism for updating / flashing BIOS and so trying to come up with a portable mechanism for updating a BIOS is destined for failure. For example when using Bochs you "update" the BIOS by specifying a different BIOS ROM image.
If you want to modifty / write your own BIOS then its going to be completely specific to that hardware. Your best bet would be to start with something like Bochs as its open source - as you can take a look at the source code for the BIOS (and easily test / debug it) you stand a reasonable chance of understanding the BIOS code and modifying it into something that works, however I suspect this isn't what you are trying to do.
Why not just perform this authentication as your OS boots? If you want to protect the data then you should encrypt it and require that the user supply log in / supply the decryption key on startup.
If you were thinking of working with "legacy" PC BIOS, I would dissuade you from trying for many of the reasons Justin mentioned: 1) legacy BIOS is PC vendor-specific; 2) it is closed source and proprietary; 3) there are no industry standards defining legacy BIOS interfaces for extending the system as you are trying to do.
On the other hand, if you have access to a UEFI-based BIOS PC, you may be able to write your own PEI/DXE driver(s) to implement such a feature. This will at least point you in the right direction:
http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome
Intel Press book on the topic: Beyond BIOS
Regarding the practicality of read/writing the BIOS, you'll need to identify the SPI part containg the BIOS and get a ROM burner. The SPI part may or may not be socketed; if it is not socketed, you'll need a soldering iron and be able to create a socket/header for the part. You obviously do not want to embark on this project with your primary computer system. Perhaps you could find an older system or a reference board.