Hot answers tagged

67

Yes, that's safe. There's nothing inherently insecure about having a hidden directory under /etc. The only reason rkhunter flags it is that it's uncommon for legitimate programs to do it, and when malware does it, it makes it less likely that you'd otherwise notice it.


61

You pretty much hit the nail on the head when you said that you need physical access to the machine. If you have physical access, you don't need to go through the official steps to reset the root password, as you can flips bits on the hard drive directly, if you know what you're doing. I.e., you can boot up a recovery OS from a DVD or flash drive, and ...


58

You can disable USB storage on Linux by blacklisting the module. modprobe -r usb-storage echo blacklist usb-storage >> /etc/modprobe.d/10-usbstorage-blacklist.conf echo blacklist uas >> /etc/modprobe.d/10-usbstorage-blacklist.conf If your users have physical access to the machine, and knows the encryption keys, the game is up no matter what ...


57

The syscall table is read-only, and has been since kernel 2.6.16. However, a kernel rootkit has the ability to make it writable again. All it needs to do is execute a function like this* with the table as the argument: static void set_addr_rw(const unsigned long addr) { unsigned int level; pte_t *pte; pte = lookup_address(addr, &level); ...


28

A call to fopen is not in itself a TOCTOU vulnerability. By definition, TOCTOU involves two operations: a “check” and a “use”. A common example of TOCTOU vulnerability is checking access permissions with access before opening a file. It's a bug (race condition) because the permissions might change between checking and opening, and it's usually a ...


27

How is this not a glaring security vulnerability? It is. Physical access to your system is the ultimate vulnerability. Is there a way to disable this 'feature' so that it cannot be changed from GRUB like this? Can you do this in all other Linux distros as well? Or is this a Redhat exclusive ability? Make yourself aware of what is happening here: ...


21

As noted by forest, modern Linux does not allow this, but it's easy to override. However, historically it was useful (and maybe still is) for security purposes: hot-patching against vulnerabilities. Back in the 1990s and early 2000s, whenever a new vulnerability was announced for a syscall I didn't absolutely need (ptrace was a really common one back then),...


21

It is safe in the sense that no, it will not make the system unstable, nor will it make it vulnerable from a security standpoint. That said, as MechMK1 points out, the only reason to use hidden directories is so that it doesn't fill the user directories with fluff they don't care about. The /etc directory, on the other hand is meant to contain such fluff, ...


21

Client-server architecture This is another approach that could make copying files much harder, but it requires investing more effort from your side. Access to the information could be setup on a client-server architecture basis with information being stored in a database (such as MySQL or PostgreSQL) on a remote server in a secure location. Then, provide ...


20

In addition to blocking USB (see other answers above): Disable networking, because... ... otherwise user will use remote access to your machine, e.g. via scp or ftp, and copy files from your machine. ... otherwise logged in users will be able to transfer file via net from your machine to some other machine via scp, ftp, samba, http.


13

OK, I'm totally not a security expert and maybe this is completely off the mark (let me know in the comments!), but... If you can secure the box physically (otherwise all bets are off), then maybe you can let the user log on only with user A. All the sensitive files however would belong to user B and inaccessible to user A. EXCEPT for one program "PDF ...


10

VNC Your files could be stored on a computer in a secure location. Setup a VNC server on it and disable file transfer capability. Per this question on ServerFault it can be done in TightVNC. Ensure no other ports are open on the computer that stores your files. Provide a VNC client station and lock it down by: disabling I/O ports in the OS and on the ...


4

Yes, you need both. The Linux-side changes make use of the microcode-side changes to mitigate these vunlerabilities, both are needed for it to work. Note that you also need to disable hyperthreading if you are really serious about mitigating this. I should add, Intel published details on how to "maybe-perhaps" mitigate it partially using some code ...


3

If you just want to disable all usb devices, have a look at usb-storage.ko (USB Mass Storage driver under Linux). Disabling the driver would affect all usb devices, keyboards/mice included. To disable the driver, you could blacklist it by modifying /etc/modprobe.d/blacklist.conf. Just add the line: blacklist usb-storage This solution assumes other users ...


2

Is it safe to encrypt twice with AES, with any mode? As long as you don't mess anything up in the implementation, the security should be at least as good as the least secure encryption. An example of such a mis-implementation (suggested by the comment) would be if you accidentally encrypted twice with AES-CTR mode using the same key and same IV (this is a ...


2

The problem is that I didn't connect my Virtual machine to the bridge adapter, so I can't get access to it. I should've just add it in the VM's settings, and all started to work well!


2

Some applications work around this by using ftp. They login to localhost with a given username. That’s more portable on some Webhosters that sudo. It is a good practice if the web server cannot modify code, because this is a very common way for permanent infection. On the other hand for convenience it’s often done. If your scripts are secure (and you don’t ...


2

Because you're not saying anything about RelRO, I'm assuming no RelRO (so no leaking of the address of strcpy because it isn't called yet). Yet, this doesn't matter much, here's why: You say PIE is enabled, which in combination with ASLR will randomize the location of the binary in memory and thus the location of the PLT and GOT. Hence you cannot leak from ...


2

How about something like a human bottleneck via procedure instead of automation and access to all files at once? All of the proposed solutions propose making the computer restrict access. This suffers from the problem that computers are ultimately stupid at the lowest level, and do what they're told. Since the HD is using whole disk encryption, all files ...


2

Following the principle of "only gives one the rights needed to achieve his task", maybe you can implement a restricted shell that will enforce that users of your system only do what you allow them to do. If your users are not able to: scp mount launch any network utility (firefox, netcat, curl) Use bash builtins to open network stream. Then the only way ...


1

Don't be afraid, this is simply one of the several servers that host OFTC service. Here is an explanation: ~$ dig +short irc.oftc.net 91.217.189.50 109.74.200.93 130.239.18.116 81.18.73.124 ~$ for ip in $(dig +short irc.oftc.net|grep -E '^[0-9]') ; do dig +short -x ${ip} ; done farad.oftc.net. solenoid.acc.umu.se. getic.rdsnet.ro. plasma.oftc.net. When ...


1

To answer your question: It's really not a good idea to let any less-than-fully-trusted process self-modify, and that's especially true for frequently-launched and highly-exposed programs like web servers. The principle of least privilege applies really strongly here, and web servers do not need the ability to self-modify. Fortunately, there are solutions. ...


1

Signing with a self signed certificate provides no value for the usual windows user. The signature is invalid from the point of Windows. The name of the signer is not shown in the elevation prompt. People who would be able to verify such a signature are equally able to verify e.g. a GPG signature which is more common in the open source community. Signing ...


1

There are projects that do exactly what you want: usbkill usbdeath (a bash script based on usbkill) usbcut (a fork of usbdeath, more friendly) I have tested, on ubuntu 18.04, usbdeath and usbcut. The difference is that usbdeath turns off the PC when inserting an unauthorized device. Instead usbcut blocks the device unauthorized (without turning off the PC)


Only top voted, non community-wiki answers of a minimum length are eligible