Differences

This shows you the differences between two versions of the page.

--- fuss:security [2019/04/29 22:44] – [Varnish and Fail2Ban] office
+++ fuss:security [2024/05/14 22:43] – [Normalizing the No-Login Shell after Debian Updates] office
@@ Line 116: / Line 116: @@
 PASS secretpassword
 </code>
+====== Normalizing the No-Login Shell after Debian Updates ======
+After successive updates and corrections, the password database might not get updated such that scanning ''/etc/passwd'' for users reveals multiple variants of the ''/usr/sbin/nologin'' shell such as:
+<code>
+systemd-coredump:x:998:998:systemd Core Dumper:/:/sbin/nologin
+rslsync:x:999:999::/home/rslsync:/sbin/nologin
+sshd:x:107:65534::/var/run/sshd:/usr/sbin/nologin
+</code>
+where the correct answer seems to be ''/usr/bin/nologin'' and as one might imagine, the other file paths do not even exist leaving an opportunity for an attacker to slide a shell into place.
+A solution to batch-change the shell for all users that have no-login shells, correcting the path, would be the following:
+<code bash>
+for i in `cat /etc/passwd | grep nologin | awk -F ':' '{ print $1 }' | xargs`; do usermod -s /usr/sbin/nologin "$i"; done
+</code>
+====== The Android Security Model is Just Liability Dumping ======
+{{fuss:fuss_security_android_liability_dumping.png?512}}
+As the title says, the Android "security model" has nothing to do with security and is just a liability dumping scheme with no value in regards to security or privacy. The same liability dumping scheme found in Android, is also implemented by platforms such as Facebook, and in spite of the fact that it is advertised as keeping users secure, it has no worth with regards to security.
+As the flowchart would imply, after downloading an application on Android, the application is a black-box with unknown capabilities that can carry out any actions it is programed to carry out. By asking the user whether they consent to various permissions to be granted, the user always takes the decision without any foreknowledge of what granting the permission would imply. In case the user denies a permission request, then, at best, the application becomes crippled, some features will not work and it and might develop some unexpected behavior at some later date (for example, in the middle of some activity, some file-transfer operation might not work, making the user wonder why), or at worst, the application will outright crash or refuse to work at all. Due to the former, the user will always take decisions, on say, arbitrary grounds: personal convictions, paranoia, guesstimates of trust, etc, when accepting or refusing the permission prompt for an application without any informed knowledge, nor any guarantee on how the application will be using the permission.
+On social media platforms, fine-grained permission controls are most of the time requested on an "all-or-nothing" basis, in the sense that the user is just presented a bulk list of permissions they would have to accept, for the application to work. If the user rejects the permission prompt, then the entire application does not work at all (which is even less than partial functionality on Android).