|Series:||Eternal Sky #2|
|Series:||Eternal Sky #2|
Kiran s Interview in Times of India (TOI) There isn t much to say apart from I haven t used it. I just didn t want to. It just is unethical. Hopefully, in the coming days GOI does something better. That is the only thing we are surviving on, hope.
Internet Freedom and Aarogya Setu App.
Internet Freedom had shared the chilling effects of the Aarogya Setu App. This had also been shared by FSCI in the past, and recently had their handle being banned on Twitter. This was also apparent in a legal bail order which the high court judge gave. While I won t go into the merits and demerits of the bail order, it is astounding for the judge to say that the accused, even though he would be on bail install an app. so he can be surveilled. And this is a high court judge, such a sad state of affairs. We seem to be putting up new lows every day when it comes to judicial jurisprudence. One interesting aspect of the whole case was shared by Aishwarya Iyer. She shared a story that she and her team worked on quint which raises questions on the quality of the work done by Delhi Police. This is of course, up to Delhi Police to ascertain the truth of the matter because unless and until they are able to tie in the PMO s office in for a leak or POTUS s office it hardly seems possible. For e.g. the dates when two heads of state can meet each other would be decided by the secretaries of the two. Once the date is known, it would be shared with the press while at the same time some sort of security apparatus would kick in place. It is incumbent, especially on the host to take as much care as he can of the guest. We all remember that World War 1 (the war to end all wars) started due to the murder of Archduke Ferdinand.
As nobody wants that, the best way is to make sure that a political murder doesn t happen on your watch. Now while I won t comment on what it would be, it would be safe to assume that it would be z+ security along with higher readiness. Especially if it as somebody as important as POTUS. Now, it would be quite a reach for Delhi Police to connect the two dates. They either will have to get creative with the dates or some other way. Otherwise, with practically no knowledge in the public domain, they can t work in limbo. In either case, I do hope the case comes up for hearing soon and we see what the Delhi Police says and contends in the High Court about the same. At the very least, it would be irritating for them to talk of the dates unless they can contend some mass conspiracy which involves the PMO (and would bring into question the constant vetting done by the Intelligence dept. of all those who work in PMO). And this whole case is to kind of shelter to the Delhi riots which happened in which majorly the Muslims died but their deaths lay unaccounted till date
Conclusion In Conclusion, I would like to share a bit of humor because right now the atmosphere is humorless, both with authoritarian tendencies of the Central Govt. and the mass mismanagement of public health which they now have left to the state to do as they fit. The peice I am sharing is from arre, one of my goto sites whenever I feel low.
exec startxso after rebooting, I ran
exec swayand to my astonishment sway started. Hooray! However, I found that
ssh-agentwasn't running so I couldn't
sshinto any servers. That's kinda a problem. Launching
ssh-agentunder openbox was buried deep in
/etc/X11/Xsession.d/90x11-common_ssh-agentand clearly was not going to happen via wayland. Since programs using
ssh-agentdepend on the environment variables
SSH_AGENT_PIDbeing globally available I thought I could simply run
$(eval ssh-agent)via my tty terminal before running
exec sway. And, that would have worked. Except... I like to add my keys via
ssh-add -cso that everytime my key is being used I get a ssh-askpass prompt to confirm the use. It seems that since
ssh-addis started before a window manager is running, it can't run the prompt. Ok, we can fix this. After searching the web, I came upon a solution of running ssh-agent via
Then, in my
# This service myst be started manually after sway # starts. [Unit] Description=OpenSSH private key agent IgnoreOnIsolate=true [Service] Type=forking Environment=SSH_AUTH_SOCK=%t/ssh-agent.socket ExecStart=/usr/bin/ssh-agent -a $SSH_AUTH_SOCK
~/.bashrcfile I have:
if [ -n WAYLAND_DISPLAY ]; then export SSH_AUTH_SOCK=/run/user/1000/ssh-agent.socket fi
$SSH_AGENT_PIDis only used by
ssh-agentto kill itself. Now that is running via
systemd- killing it should be do-able without a global environment variable. Done? Hardly. I've been using
assword) happily for years but alas it is tightly integrated with
xclip. So... I've switched to
keepassxcwhich works out of the box with wayland. My next challenge was the status bar. Farewell faithful tint2. One of the reasons I failed on my first two attempts to switch to Sway was the difficulty of getting the swaybar to work how I wanted, particularly with nm-applet. Two things allowed me to move forward:
xclipwith wl-clipboard was a little tedious but really not that difficult. Getting my screen shot and screen recorder functionality was a bit harder. I did a lot of searching before I finally found and compiled both swappy, screen shot and wf-recorder. In the course of all my adventures, I came across the following helpful tips:
libreoffice-gtk3to ensure libre office runs under wayland
MOZ_ENABLE_WAYLANDto ensure firefox works properly.
ssh-addcommand to ensure I am prompted for each use of my key seems to cause sway to crash intermittently.
export XDG_SESSION_TYPE=waylandto my
.bashrc, and after hours of frustration, realize that I needed to configured firejail to allow it so that I can share my entire screen in Firefox. It doesn't yet support sharing a specific window, so I still have to keep chromium around for that (and Chromium can only share xwayland windows). Sigh. Oh, one more thing about Firefox: the option to choose what to share doesn't have "Entire Screen" as an option, you are just supposed to know that you should choose "Use operating system settings".
~/.config/sway/configfile I have:
bindsym Mod4+e exec wtype " ". I have repeated that line for the main accent marks I need.
about:configin the Firefox location window, searching for
privacy.webrtc.legacyGlobalIndicatorand setting it to False. The reddit thread also suggested finding
privacy.webrtc.hideGlobalIndicatorand setting it to True, but that setting doesn't seem to be available and setting the first one alone seems to do the trick.
GDK_BACKEND=wayland,x11. First I just set it to wayland to get gtk3 apps to use wayland (like gajim). But that broke electron apps (like signal) which notice that variable but don't have a way to display via wayland (at least not yet). Setting it to "wayland,x11" shows the priority. Thank you ubuntu community.
~/.config/sway/env. That seems like an official sway place to put them, but sway doesn't pay any attention to them. So I start sway via my own bash script which sources that file via
[ -f "$HOME/.config/sway/env" ] && . "$HOME/.config/sway/env"before
CONFIG_VMAP_STACKfor arm64, which moves the kernel stack to an isolated and guard-paged vmap area. With traditional stacks, there were two major risks when exhausting the stack: overwriting the
thread_infostructure (which contained the
addr_limitfield which is checked during
copy_to/from_user()), and overwriting neighboring stacks (or other things allocated next to the stack). While arm64 previously moved its thread_info off the stack to deal with the former issue, this vmap change adds the last bit of protection by nature of the vmap guard pages. If the kernel tries to write past the end of the stack, it will hit the guard page and fault. (Testing for this is now possible via LKDTM s
STACK_GUARD_PAGE_LEADING/TRAILINGtests.) One aspect of the guard page protection that will need further attention (on all architectures) is that if the stack grew because of a giant Variable Length Array on the stack (effectively an implicit
alloca()call), it might be possible to jump over the guard page entirely (as seen in the userspace Stack Clash attacks). Thankfully the use of VLAs is rare in the kernel. In the future, hopefully we ll see the addition of PaX/grsecurity s STACKLEAK plugin which, in addition to its primary purpose of clearing the kernel stack on return to userspace, makes sure stack expansion cannot skip over guard pages. This stack probing ability will likely also become directly available from the compiler as well.
addr_limitfield mentioned above, another class of bug is finding a way to force the kernel into accidentally leaving
addr_limitopen to kernel memory through an unbalanced call to
set_fs(). In some areas of the kernel, in order to reuse userspace routines (usually VFS or compat related), code will do something like:
set_fs(KERNEL_DS); ...some code here...; set_fs(USER_DS);. When the
USER_DScall goes missing (usually due to a buggy error path or exception), subsequent system calls can suddenly start writing into kernel memory via
copy_to_user(where the to user really means within the
addr_limitrange ). Thomas Garnier implemented USER_DS checking at syscall exit time for x86, arm, and arm64. This means that a broken
set_fs()setting will not extend beyond the buggy syscall that fails to set it back to
USER_DS. Additionally, as part of the discussion on the best way to deal with this feature, Christoph Hellwig and Al Viro (and others) have been making extensive changes to avoid the need for
set_fs()being used at all, which should greatly reduce the number of places where it might be possible to introduce such a bug in the future. SLUB freelist hardening
CONFIG_SLAB_FREELIST_HARDENED, makes freelist pointer overwrites very hard to exploit unless an attacker has found a way to expose both the random value and the pointer location. This should render blind heap overflow bugs much more difficult to exploit. Additionally, Alexander Popov implemented a simple double-free defense, similar to the fasttop check in the GNU C library, which will catch sequential
free()s of the same pointer. (And has already uncovered a bug.) Future work would be to provide similar metadata protections to the SLAB allocator (though SLAB doesn t store its freelist within the individual unused objects, so it has a different set of exposures compared to SLUB). setuid-exec stack limitation
CONFIG_GCC_PLUGIN_RANDSTRUCT, now includes one of the major targets of exploits: function pointer structures. Without knowing the build-randomized location of a callback pointer an attacker needs to overwrite in a structure, exploits become much less reliable. structleak passed-by-reference variable initialization
CONFIG_GCC_PLUGIN_STRUCTLEAK_BYREF_ALL. Normally the compiler will yell if a variable is used before being initialized, but it silences this warning if the variable s address is passed into a function call first, as it has no way to tell if the function did actually initialize the contents. So the plugin now zero-initializes such variables (if they hadn t already been initialized) before the function call that takes their address. Enabling this feature has a small performance impact, but solves many stack content exposure flaws. (In fact at least one such flaw reported during the v4.15 development cycle was mitigated by this plugin.) improved boot entropy
SECCOMP_FILTER_FLAG_LOG, he added a new action result,
SECCOMP_RET_LOG. With these changes in place, it should be much easier for developers to inspect the results of seccomp filters, and for process launchers to generate logs for their child processes operating under a seccomp filter. Additionally, I finally found a way to implement an often-requested feature for seccomp, which was to kill an entire process instead of just the offending thread. This was done by creating the
SECCOMP_RET_ACTION_FULLmask (n e
SECCOMP_RET_ACTION) and implementing
SECCOMP_RET_KILL_PROCESS. That s it for now; please let me know if I missed anything. The v4.15 merge window is now open!
2017, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
It might be possible to make the graph much better than it is currently . The Profit and Loss Account of the Government tells what Incomes it is projected to earn in the upcoming year and whatever Expenditures it hopes to do this year. The Income and Expenditure independently can be bifurcated into two, Revenue Income and Capital Income and Revenue Expenditure and Capital Expenditure. The simplest example of such planned expenditure which comes to my mind is the Indian Railways Budget which is all planned expenditure. As can be seen even with ample funds Railways were able to spent only 50% of the total amount disbursed last year. Similarly income generation for Railways was far below the target. Examples of Revenue Income include taxes of all sorts, while Capital Income are rare, like divestment/stake sale of a company owned by the Government. These are usually one-off events. Examples of Capital Expenditure is when the Government makes a road, makes a bridge etc. Usually large expenditures come under Capital Expenditure while salaries to Government employees and routine expenditures are known as Revenue Expenditure. There was a statement by the present Government that the last 6-7 years the budgets has been more or less static as far as numbers are concerned. This hampers Government s ability to take up any new work. The Revenue income earned by the Government can again be bifurcated primarily into two Direct Taxes and Indirect Taxes. Direct Taxes are those which the Government earns through Personal Income Tax and Corporate Tax. As only 1 percent of Indians pay Personal income tax, the rest Government tries to raise by
Country_Budget -- Profit_and_Loss_Account [type=s];
RDRAND(though most have an instruction counter like x86 s
RDTSC), but it does have the benefit of being able to use Device Tree (i.e. the
/chosen/kaslr-seedproperty) like arm64 does. By my understanding, even without Device Tree, MIPS KASLR entropy should be as strong as pre-RDRAND x86 entropy, which is more than sufficient for what is, similar to x86, not a huge KASLR range anyway: default 8 bits (a span of 16MB with 64KB alignment), though
CONFIG_RANDOMIZE_BASE_MAX_OFFSETcan be tuned to the device s memory, giving a maximum of 11 bits on 32-bit, and 15 bits on EVA or 64-bit. SLAB freelist ASLR Thomas Garnier added CONFIG_SLAB_FREELIST_RANDOM to make slab allocation layouts less deterministic with a per-boot randomized freelist order. This raises the bar for successful kernel slab attacks. Attackers will need to either find additional bugs to help leak slab layout information or will need to perform more complex grooming during an attack. Thomas wrote a post describing the feature in more detail here: Randomizing the Linux kernel heap freelists. (SLAB is done in v4.7, and SLUB in v4.8.) eBPF JIT constant blinding Daniel Borkmann implemented constant blinding in the eBPF JIT subsystem. With strong kernel memory protections (
CONFIG_DEBUG_RODATA) in place, and with the segregation of user-space memory execution from kernel (i.e SMEP, PXN,
CONFIG_CPU_SW_DOMAIN_PAN), having a place where user-space can inject content into an executable area of kernel memory becomes very high-value to an attacker. The eBPF JIT was exactly such a thing: the use of BPF constants could result in the JIT producing instruction flows that could include attacker-controlled instructions (e.g. by directing execution into the middle of an instruction with a constant that would be interpreted as a native instruction). The eBPF JIT already uses a number of other defensive tricks (e.g. random starting position), but this added randomized blinding to any BPF constants, which makes building a malicious execution path in the eBPF JIT memory much more difficult (and helps block attempts at JIT spraying to bypass other protections). Elena Reshetova updated a 2012 proof-of-concept attack to succeed against modern kernels to help provide a working example of what needed fixing in the JIT. This serves as a thorough regression test for the protection. The cBPF JITs that exist in ARM, MIPS, PowerPC, and Sparc still need to be updated to eBPF, but when they do, they ll gain all these protections immediatley. Bottom line is that if you enable the (disabled-by-default)
bpf_jit_enablesysctl, be sure to set the
bpf_jit_hardensysctl to 2 (to perform blinding even for root). fix brk ASLR weakness on arm64 compat There have been a few ASLR fixes recently (e.g. ET_DYN, x86 32-bit unlimited stack), and while reviewing some suggested fixes to arm64 brk ASLR code from Jon Medhurst, I noticed that arm64 s brk ASLR entropy was slightly too low (less than 1 bit) for 64-bit and noticeably lower (by 2 bits) for 32-bit compat processes when compared to native 32-bit arm. I simplified the code by using literals for the entropy. Maybe we can add a sysctl some day to control brk ASLR entropy like was done for mmap ASLR entropy. LoadPin LSM LSM stacking is well-defined since v4.2, so I finally upstreamed a small LSM that implements a protection I wrote for Chrome OS several years back. On systems with a static root of trust that extends to the filesystem level (e.g. Chrome OS s coreboot+depthcharge boot firmware chaining to dm-verity, or a system booting from read-only media), it s redundant to sign kernel modules (you ve already got the modules on read-only media: they can t change). The kernel just needs to know they re all coming from the correct location. (And this solves loading known-good firmware too, since there is no convention for signed firmware in the kernel yet.) LoadPin requires that all modules, firmware, etc come from the same mount (and assumes that the first loaded file defines which mount is correct , hence load pinning ). That s it for v4.7. Prepare yourself for v4.8 next!
2016, Kees Cook. This work is licensed under a Creative Commons Attribution-ShareAlike 3.0 License.
Only ONE of us is the kind of person that goes up to guys with machine guns to ask what s happening. Me to Terah todayThey told me that it was the preparations for the opening ceremony for a global shooting contest, and also gave me directions to the bus stop.
amixer -q sset Beep offto shut up
walland other such tools. (I made an init.d script to make that happen automatically, and to make sure I don't forget it when I install new machines for myself.)
flightplan, and others on
#debian-develwith help on shutting up