Missing my /etc/sysctl.d/sysctl.conf , what can be done?

[bonkers]

I am follwing this guide, and I am missing my /etc/sysctl.d/sysctl.conf file, what can I do to amend this situation? Here is what is currently in there.

[bonkers]

For instance the file /etc/sysctl.d/10-magic-sysrq.conf is

 			 				# The magic SysRq key enables certain keyboard combinations to be
# interpreted by the kernel to help with debugging. The kernel will respond
# to these keys regardless of the current running applications.
#
# In general, the magic SysRq key is not needed for the average Ubuntu
# system, and having it enabled by default can lead to security issues on
# the console such as being able to dump memory or to kill arbitrary
# processes including the running screen lock.
#
# Here is the list of possible values:
#   0 - disable sysrq completely
#   1 - enable all functions of sysrq
#  >1 - enable certain functions by adding up the following values:
#          2 - enable control of console logging level
#          4 - enable control of keyboard (SAK, unraw)
#          8 - enable debugging dumps of processes etc.
#         16 - enable sync command
#         32 - enable remount read-only
#         64 - enable signalling of processes (term, kill, oom-kill)
#        128 - allow reboot/poweroff
#        256 - allow nicing of all RT tasks
#
#   For example, to enable both control of console logging level and
#   debugging dumps of processes: kernel.sysrq = 10
#
kernel.sysrq = 176

I read that this overrides /etc/sysctl, but where is /etc/sysctl.d/sysctl.conf ? Also why 176?

Changelog

procps (1:3.3.3-2ubuntu2) quantal; urgency=low

* Add debian/sysctl.d/10-magic-sysrq.conf: disable the magic sysrq key
by default, since it's not needed for the average system, and exposes
security issues such as memory disclosure and killing arbitrary
processes including the screen lock. (LP: #194676)
-- Marc Deslauriers <marc.deslauriers@ubuntu.com> Thu, 21 Jun 2012 08:19:56 -0400

[bonkers]

I also found this configuration which has me a little worried in /etc/sysctl.d/ , a file named 30-baloo-inotify-limit.conf which has

fs.inotify.max_user_watches = 524288

On this page I found the following statement, and I quote:

For an intelligent IDE it is essential to be in the know about any external changes in files it working with - e.g. changes made by VCS, or build tools, or code generators etc. For that reason, IntelliJ platform spins background process to monitor such changes. The method it uses is platform-specific; and on Linux it is Inotify facility.
Inotify requires a "watch handle" to be set for each directory in the project. Unfortunately, the default limit of watch handles may not be enough for reasonably sized projects, and reaching the limit will force IntelliJ platform to fall back to recursive scans of directory trees.
To prevent this situation it is recommended to increase the watches limit (to, say, 512K). You can do it by adding following line to the /etc/sysctl.conf file:

fs.inotify.max_user_watches = 524288

Then run this command to apply the change:

sudo sysctl -p

And don't forget to restart your IDE.

Note: the watches limit is per-account setting. If there are other programs running under the same account which also uses Inotify the limit should be raised high enough to suite needs of all of them.

I found this on wiki which states :

The first version of IntelliJ IDEA was released in January 2001, and at the time was one of the first available Java IDE with advanced code navigation and code refactoring capabilities integrated.^[3][4]
Google is developing a product called Android Studio, an open source Android Development IDE based on the open source community edition of IntelliJ IDEA

I had a problem with an Android phone, someone broke into it and basically made it unusable, changed all permissions, my busybox and permission denied and other apps were all edited to this persons liking, I made the mistake of rooting it, the whole thing was totally broken into, someone installed applications that I later found...big headache. And the phone was connected to this linux box.

[SteveRiley]

I am follwing this guide, and I am missing my /etc/sysctl.d/sysctl.conf file, what can I do to amend this situation?

You do realize that you're following a guide for a different distribution, right? Siduction is not a derivative or flavor of Ubuntu. Ubuntu and its flavors do not have a /etc/sysctl.d/sysctl.conf file. If you're going to follow guides for distributions that are not based on Ubuntu, then you'll need to adapt the guidance appropriately. The file /etc/sysctl.d/README can help you understand the layout of the sysctl configuration files.

Furthermore, you should know that the change to systemd will affect how various distributions use these files. For instance, in Arch Linux, the file /etc/sysctl.conf is ignored completely -- it is required that all settings be made in the various separate files in the sysctl.d subdirectory. I don't know whether the same applies to Ubuntu and its flavors, because I haven't (yet) converted to systemd.

Here is what is currently in there.

Your screenshots are very difficult to read, because the contrast level between dark green and black is low. A light theme would be helpful for screenshots posted to the forum.

---

For instance the file /etc/sysctl.d/10-magic-sysrq.conf is
...
I read that this overrides /etc/sysctl, but where is /etc/sysctl.d/sysctl.conf ?

No, your interpretation is incorrect. The README file I referenced earlier mentions the following: "End-users can use 60-*.conf and above, or use /etc/sysctl.conf directly, which overrides anything in this directory." Configuration files in /etc/sysctl/sysctl.d are processed in numerical order. Directives in files that start with higher numbers will override directives in files that start with lower numers. Finally, directives in /etc/sysctl.conf will override anything else.

Also why 176?

Please note the following line in the file's comments:

#  >1 - enable certain functions by adding up the following values:

It's a simple matter of subtraction to determine what 176 means.

---

I also found this configuration which has me a little worried in /etc/sysctl.d/ , a file named 30-baloo-inotify-limit.conf which has
...
I found this on wiki which states :
...
I had a problem with an Android phone, someone broke into it and basically made it unusable

What makes you think that there is any relationship at all between increasing the number of inotify watches and some problem with your Android phone? Do you know what inotify is? Do you understand what Baloo is, and why it benefits from a higher inotify watch limit? Hint: it's the same reason that an IDE benefits from a higher inotify watch limit.

Absolutely none of the above has anything to do with your compromised phone. However, if someone did attack your phone, you should know that you can't trust it. Your highest priority should be to wipe all partitions, plus the recovery and the bootloader. Then flash a clean bootloader, recovery, and Android ROM. Caution: if you don't know how to do this, find a friend who does. Incorrectly flashing images -- especially a bootloader -- can permanently brick a phone.