Google Bard on file system immutability flags in OpenBSD

 Unlike ChatGPT, Bard pretty much nailed it on the initial prompt. (However, Bard refused to answer my questions about the Mars Effect like the ones I gave to ChatGPT, even when reworded to be clear I was asking for descriptions of what the effect is and what explanations are offered rather than asking it to identify causes itself.)

It does lose points for grammar in the second sentence, though!

write a few paragraphs explaining immutable flags in OpenBSD including the commands for setting them and the difference between system and user immutable flags

Sure. Here is a few paragraphs explaining immutable flags in OpenBSD, including the commands for setting them and the difference between system and user immutable flags.

Immutable Flags

Immutable flags are a security feature in OpenBSD that prevent files from being modified, moved, or deleted. They can be set on any file by the superuser, or on files owned by the current user with the chflags command.

To set the immutable flag on a file, use the following command:

chflags schg filename

To unset the immutable flag, use the following command:

chflags nouchg filename

System and User Immutable Flags

There are two types of immutable flags: system immutable and user immutable. System immutable flags are set by the superuser and can only be cleared by the superuser at security level 0 or -1. User immutable flags are set by the owner of the file and can be cleared by the owner of the file at any time.

Commands for Setting Immutable Flags

The following commands can be used to set immutable flags:

• chflags schg filename: Sets the system immutable flag on filename.
• chflags uappnd filename: Sets the user append-only flag on filename.

Difference Between System and User Immutable Flags

The main difference between system and user immutable flags is that system immutable flags can only be cleared by the superuser at security level 0 or -1, while user immutable flags can be cleared by the owner of the file at any time.

Example

The following example shows how to set the immutable flag on a file and then clear it:

# Set the immutable flag on the file /etc/passwd
chflags schg /etc/passwd

# Clear the immutable flag on the file /etc/passwd
chflags nouchg /etc/passwd

Benefits of Using Immutable Flags

Immutable flags can be used to improve the security of your system by preventing unauthorized changes to critical files. For example, you could use immutable flags to protect system configuration files, such as /etc/passwd and /etc/shadow, from being modified by attackers.

Disadvantages of Using Immutable Flags

There are a few disadvantages to using immutable flags. First, they can make it difficult to troubleshoot problems with your system. If a file that is set to immutable is corrupted, you will not be able to modify it to fix the problem. Second, immutable flags can slow down your system performance, especially if a large number of files are set to immutable.

Conclusion

Immutable flags are a powerful security feature that can be used to protect your system from unauthorized changes. However, it is important to weigh the benefits and disadvantages of using immutable flags before deciding whether or not to use them on your system.

Trurl's Electronic Bard vs. ChatGPT

In Stanislaw Lem's book, The Cyberiad: Fables for the Cybernetic Age (1974 English translation, page numbers from the 1985 Harvest/HBJ Book), he writes of Trurl's Electronic Bard, a machine that generates poetry to specification. In the first example of a prompt, Klapaucius asks Trurl to (p. 50):

"Have it compose a poem--a poem about a haircut! But lofty, noble, tragic, timeless, full of love, treachery, retribution, quiet heroism in the face of certain doom! Six lines, cleverly rhymed, and every word beginning with the letter s!"

Here's what ChatGPT came up with (which it titled "Haircut Horror"):

Compose a poem--a poem about a haircut! But lofty, noble, tragic, timeless, full of love, treachery, retribution, quiet heroism in the face of certain doom! Six lines, cleverly rhymed, and every word beginning with the letter s!

She sat in the salon chair, serene Scissors snipping, strands of hair careen Suddenly, a gasp, a scream She surveys the mirror, it would seem Sheer horror, a mistake extreme She'll seek solace in a hair care regime.

ChatGPT didn't quite follow the rules.  Here's what Trurl's Electronic Bard composed (p. 51):

Seduced, shaggy Samson snored.

She scissored short. Sorely shorn,

Soon shackled slave, Samson sighed,

Silently scheming,

Sightlessly seeking,

Some savage, spectacular suicide.

Point awarded to the Electronic Bard (or really, to Lem and to Lem's translators, who wrote multiple poems to similarly absurd specifications in numerous languages).

UPDATE (14 June 2024): Dimitri Papaioannou had the same idea a month earlier.

ChatGPT and the Economist weekly trivia quiz

 Each week The Economist runs a trivia quiz of five questions, one each weekday, which are linked by a common but not necessarily obvious theme. This week's quiz had a fairly obvious theme, and yesterday I decided to see if ChatGPT could answer the questions and identify the theme. The results show how ChatGPT is very good at directed search--it got four of the five answers on the first try and got the fifth answer with a small amount of guidance with a single question. But it is not so good at inference (and isn't actually engaged in inference)--it suggested themes, with seeming confidence, that did not link all five answers together, and I didn't successfully guide it to the best answer, a theme which was simple enough that I was able to identify it after the second day's question. The error at the end is likely because I stepped away and came back a few minutes later before adding the last question, rather than because ChatGPT couldn't handle it.

Can you answer these five questions and identify the theme that links
the answers together? (1) Which small hand tool for boring holes is
also used to describe a piercing stare? (2) What was the code name
given to the development of the nuclear bomb during the second world
war? (3) Which magazine did Helen Gurley Brown edit for 32 years? (4)
What is the name for a one-wheeled passenger seat attached to a
motorcycle or scooter? (5) What menace features in the TV shows "Black
Summer" and "The Walking Dead"?

(1) Drill (2) Manhattan Project (3) Cosmopolitan (4) Sidecar (5) Zombies

The theme linking these answers is "Tools and Things associated with Survival."

Is there another possible answer to the first question which would
identify a different theme that makes more sense of the other answers?

Yes, another possible answer to the first question is "Gimlet".

The theme linking these answers is "Tools and Things associated with
manual labor".

The gimlet answer is better, but none of those things are tools or are
associated with manual labor. Given the new list of answers, is there
a different theme you can identify?

Yes, another possible theme for the answers is "Popular Culture".

The answers can be associated with various forms of popular culture
including: (1) Gimlet, a tool that is also a type of cocktail (2)
Manhattan Project, a historical event that has inspired numerous
movies, books and video games (3) Cosmopolitan, a women's magazine
with a focus on fashion, beauty, relationships and pop culture (4)
Sidecar, a passenger seat that is a common fixture in motorcycle and
scooter cultures (5) Zombies, a popular monster that has been featured
in many TV shows, movies, books, and video games.

If you drop the word "Project" from "Manhattan Project", does that
suggest another theme?

Yes, dropping the word "Project" from "Manhattan Project" suggests
another possible theme of "Cities".

(1) Gimlet, a cocktail named after a tool, is associated with cities
known for their nightlife such as London and New York. (2) Manhattan,
a famous city and global financial center. (3) Cosmopolitan, a
magazine focused on city life and culture. (4) Sidecar, a mode of
transportation commonly used in cities. (5) Zombies, a popular monster
often associated with urban areas in popular culture.

You have identified a gimlet as a drink, are any of the other answers
also associated with drinks? Does that suggest another possible theme?

Yes, (3) Cosmopolitan is also associated with a drink, the
Cosmopolitan cocktail.

The theme linking these answers could be "Drinks and Things Named After Them".

(1) Gimlet, a cocktail named after a tool (2) Manhattan, a cocktail
named after the city (3) Cosmopolitan, a women's magazine and a
cocktail named after it (4) Sidecar, a cocktail named after a mode of
transportation (5) Zombies, a popular monster often depicted consuming
human flesh, but not named after a drink.

If answer five is singular instead of plural, does that give a clearer
theme for the five answers?

Yes, if answer five is singular instead of plural, it provides a clearer theme.

The theme linking these answers could be "Named after Popular Culture".

(1) Gimlet, a tool named after a cocktail (2) Manhattan, a cocktail
named after the city and a code name for the development of the
nuclear bomb during World War II (3) Cosmopolitan, a women's magazine
and a cocktail named after it (4) Sidecar, a passenger seat and a
cocktail named after it (5) Zombie, a popular monster often depicted
in popular culture.

Isn't there a cocktail called a Zombie?
!

An error occurred. If this issue persists please contact us through
our help center at help.openai.com.

Some nonsense from ChatGPT about file system immutability flags in OpenBSD

 I was thinking about writing a blog post about file system immutability flags in OpenBSD, and thought I'd ask ChatGPT to write it for me. It appears to have gleaned its content from OpenBSD man pages, but it is highly misleading and inaccurate, misrepresenting the key distinction between system and user immutability flags.

What it got right is that only the superuser (root) can set and unset the system immutability flag (schg/noschg) while users (if they own the file) can set and unset the user immutability flag (uchg/nouchg). But either flag can be set or unset on any kind of file.

The user immutability flag can be unset (nouchg) by either the superuser or the owner of the file regardless of the system security run level (-1 to 2), but the system immutability flag can only be unset (noschg) by the superuser when the system security run level is 0 (insecure mode) or -1 (permanently insecure mode).

During boot, the system normally starts in single-user mode at security run level 0. The init process raises the run level to 1 (secure mode) when booting to multi-user mode, and to 2 (highly secure mode) if the rc.securelevel config file so specifies. The system secure level can also be raised if the superuser changes it with the sysctl command, setting the kern.securelevel variable. The permanently insecure mode (-1) can be set with sysctl only while in insecure mode, which will cause the init process to not raise the security level to 1 during boot to multi-user mode.

The man page for securelevel gives an overview of the restrictions at each security level. I run my systems at secure level 2, highly secure mode. Secure mode (secure level = 1) and above prevent lowering the secure level except by the init process (when the system is shutdown back to single user mode), do not allow /dev/mem or /dev/kmem to be opened, make raw disk devices read only, and disallow unsetting of system immutability flags (or unsetting the related system append-only flags, sappnd, using nosappnd), along with a few other restrictions. Highly secure mode (securelevel = 2) also prevents setting the time backward or close to overflow, and prevents changing host firewall rules (pf filter and NAT rules), though IP addresses may still be added or removed from tables. The most significant difference between the system and user immutability flags is not what files they are set on, but that the user immutability flags can be turned off at any time by the file owner or superuser, while the system immutability flags can only be changed while in insecure modes, i.e., after a shutdown from multi-user operation.

I use system file immutability flags on most configuration files, system binaries, and system libraries as an obstacle to an attacker in the event of a compromise and escalation of privileges. If an attacker has console access to a system, they can bypass these flags by shutting down the system and unsetting the flags. If I left certain config files without file system immutability flags set, an attacker could modify one of those config files that leads to execution during system startup to insert commands to unset the flags, and then reboot the system so that those commands execute while the system is in insecure mode.

These flags can get in the way and cause problems without an efficient way to manage them, as they need to be unset in order to do system patches and updates--it's bad news if you try to do a system upgrade while many files are set with immutability flags. They also block features like OpenBSD's kernel address randomized link (KARL) and library reordering address space layout randomization (ASLR) features, which relink the kernel and certain key libraries on reboot to make blind return-oriented programming (BROP) attacks more difficult. I use scripts called syslock/sysunlock to manage the immutability flags. These scripts have a config file (kept immutable, of course) that specifies which files and directory contents to set immutable, and defines groups so that I can unlock what I need at a particular time with a single command. When I want to allow KARL and library ASLR to occur, I do a sysunlock -s (unlock system files) while in single user mode and then boot. I've also defined groups for things like "everything in /etc", "everything related to DNS", etc.

My rc.securelevel config file contains a command to sleep for a period of time, then do a syslock -s after raising the system security level, giving the system time to do the relinking, so I don't need to issue a command to re-lock those files. This is a process I also follow when installing kernel patches, as syspatch fails to do kernel relinking when in single-user mode. That is, I boot to single-user mode, unlock the system files with "sysunlock -s", then exit back to multi-user mode and the KARL process (/usr/libexec/reorder_kernel) and library ASLR (part of /etc/rc) run without error.

syslock/sysunlock may be found at https://www.discord.org/lippard/software/ and on Github at https://github.com/lippard661/syslock

Anyway, after that long introduction, here's what ChatGPT had to say about all this; my prompts are in red:

write a few paragraphs explaining immutable flags in OpenBSD including the commands for setting them and the difference between system and user immutable flags

In OpenBSD, immutable flags are used to protect files from being modified or deleted. These flags can be set on both system and user files, and are useful for preventing accidental or malicious changes to important system files.

To set an immutable flag on a file, the "chflags" command can be used. The command takes the form "chflags immutable [filename]" and can be used to set the flag on a single file or multiple files at once. To remove the immutable flag, the command "chflags noschg [filename]" can be used.

The difference between system and user immutable flags is the level of protection they provide. System immutable flags are set on system files and are only modifiable by the superuser. User immutable flags are set on user files and can be modified by the owner of the file. This allows users to protect their own files, while also allowing the system administrator to protect important system files.

It's important to note that while immutable flags provide a level of protection, they should not be considered as a replacement for proper file permissions and security practices. It's still important to use appropriate permissions to control access to files and to keep your system updated to protect against known vulnerabilities.

Can I set the user immutable flag on a system file or the system immutable flag on a user file?

In OpenBSD, the system immutable flag can only be set on system files, and the user immutable flag can only be set on user files. Attempting to set a user immutable flag on a system file or a system immutable flag on a user file will result in an error.

This is because the system immutable flag is intended for use on system files that should not be modified by anyone other than the superuser. Setting this flag on a user file would not provide any additional security, as the user already has full control over their own files. Similarly, the user immutable flag is intended for use on user files that should not be modified by the owner. Setting this flag on a system file would not provide any additional security, as the superuser already has the ability to modify system files.

It's important to use the appropriate immutable flag for the type of file you are working with to ensure that the file is protected as intended.

[UPDATE, 22 Jan 2023:]

That is incorrect. The system immutable flag can be set on user files and the user immutable flag can be set on system files. The difference is not what files they can be used on, but that the system immutable flag can only be unset by the superuser when the system is in insecure mode, while the user immutable flag can be unset by the file owner or superuser at any system security run level.

I apologize, you are correct. The system immutable flag can be set on user files, and the user immutable flag can be set on system files. The difference between the two flags is not the type of file they can be applied to, but rather the level of protection they provide and who can unset them.

The system immutable flag provides a higher level of protection and can only be unset by the superuser when the system is in insecure mode, This means that once the system flag is set, the file cannot be modified or deleted without booting in insecure mode.

On the other hand, the user immutable flag can be unset by the file owner or the superuser at any system security run level. This means that the file can be modified or deleted by the owner of the file or superuser at any time.

Again, I apologize for the confusion in my previous answer. Thank you for bringing this to my attention.

Books read in 2022

 Not much blogging going on here still, but here's my annual list of books read for 2022.

• Heather Adkins, Betsy Beyer, Paul Blankinship, Piotr Lewandowski, Ana Oprea, and Adam Stubblefield, Building Secure and Reliable Systems: Best Practices for Designing, Implementing, and Maintaining Systems (2020)
• Oliver Bullough, Butler to the World: How Britain Helps the World's Worst People Launder Money, Commit Crimes, and Get Away with Anything
• David Edmonds, The Murder of Professor Schlick: The Rise and Fall of the Vienna Circle (2020)
• Ada Ferrer, Cuba: An American History
• Paul Fisher, House of Wits: An Intimate Portrait of the James Family (2008)
• Robert W. Gehl and Sean T. Lawson, Social Engineering: How Crowdmasters, Phreaks, Hackers, and Trolls Created a New Form of Manipulative Communication (available via Open Access)
• Adam Gorightly, Saucers, Spooks and Kooks: UFO Disinformation in the Age of Aquarius (2021)
• Garrett M. Graff, Watergate: A New History
• Andy Greenberg, Tracers in the Dark: The Global Hunt for the Crime Lords of Cryptocurrency
• Jan T. Gregor with Tim Cridland, Circus of the Scars: The True Inside Odyssey of a Modern Circus Sideshow (1998)
• Thomas Harman, Esq., A Caveat or Warning for Common Cursetors, Vulgarly Called Vagabonds (1814 reprint of 1566 pamphlet)
• N.K. Jemisin, The City We Became (2020)
• Thomas Levenson, Money for Nothing: The Scientists, Fraudsters, and Corrupt Politicians Who Reinvented Money, Panicked a Nation, and Made the World Rich (2020)
• Michael Lewis, The Premonition: A Pandemic Story (2021)
• Michael W. Lucas, OpenBSD Mastery: Filesystems
• Alan C. Logan, The Greatest Hoax on Earth: Catching Truth, While We Can (2020)
• David McRaney, How Minds Change: The Surprising Science of Belief, Opinion, and Persuasion
• Tim Miller, Why We Did It: A Travelogue from the Republican Road to Hell
• Jefferson Morley, Scorpions' Dance: The President, the Spymaster, and Watergate
• Wes Patience, From Bjäre to Bisbee: An Immigrant's Tale (2006)
• Douglas Rushkoff, Survival of the Richest: Escape Fantasies of the Tech Billionaires
• Sara Schaefer, Grand: A Memoir (2020)
• P.W. Singer and August Cole, Burn-In: A Novel of the Real Robotic Revolution (2020)
• Seth Stephens-Davidowitz, Don't Trust Your Gut: Using Data to Get What You Really Want In Life
• Stuart Stevens, It Was All a Lie: How the Republican Party Became Donald Trump (2020)
• Will Storr, The Status Game: On Human Life and How to Play It
• Terry Teachout, The Skeptic: A Life of H.L. Mencken (2002)
• Michal Zalewski, Practical Doomsday: A User's Guide to the End of the World

Top for 2022: Ferrer, Levenson, Graff, Greenberg, Miller, Zalewski, McRaney, Storr, Logan (even though it's a 2020 book), Jemisin (likewise)

A few planned reads for 2023 (mostly already started):

G.A. Cohen, Self-Ownership, Freedom, and Equality (1995)

John Ferris, Behind the Enigma: The Authorised History of GCHQ, Britain's Secret Cyber-Intelligence Agency (2020)

Final Report of the Select Committee to Investigate the January 6th Attack on the United States Capitol

Kevin M. Levin, Searching for Black Confederates: The Civil War's Most Persistent Myth (2019)

Chris A. Rutkowski, Canada's UFOs: Declassified (2022)

Will Sommer, Trust the Plan: The Rise of QAnon and the Conspiracy That Unhinged America (pre-ordered, to be released in late Feb 2023)

Steve Vladeck, The Shadow Docket: How the Supreme Court Uses Stealth Rulings to Amass Power and Undermine the Republic (pre-ordered, to be released in late May 2023)

Peter H. Wilson, The Holy Roman Empire: A Thousand Years of Europe's History (2017)

(Previously: 2021, 2020, 2019, 2018, 2017, 2016, 2015, 2014, 2013, 2012, 2011, 2010, 2009, 2008, 2007, 2006, 2005.) 

ChatGPT on the Mars Effect

 ChatGPT gets a lot of things wrong here. The Zelen Test is a test that expected to find that the Mars effect correlations in Gauquelin's data were due to the nycthemeral curve, a variation in the likelihood of birth at particular times of the day, but the test showed the opposite. (There is also a more generic Zelen test in statistics that is the source of some of what ChatGPT says here.) It did not debunk the Mars effect, it showed that any correlation must be due to something else. Dennis Rawlins was an opponent of the test because he thought there was a statistical artifact in the data that was a result of sampling bias or other cause, and expected this outcome. He fiercely argued against any idea that the Mars effect was a real "cosmobiological" phenomenon. The bibliography of Dennis Rawlins-authored articles is complete fiction, none of those articles exist. Here's the chat, with my prompts in red:

what is the cause of the Mars Effect

The "Mars effect" refers to the supposed correlation between the position of the planet Mars in the sky at the time of a person's birth and their success or greatness. The idea of the Mars effect was popularized by French astrologer Michel Gauquelin in the 1950s and 1960s, who claimed to have found statistical evidence supporting the idea that people born when Mars was prominent in the sky were more likely to be successful or accomplished. However, subsequent research has failed to replicate Gauquelin's findings and the Mars effect has been widely debunked as a statistical artifact. There is no scientific basis for the idea that the position of Mars at the time of a person's birth has any influence on their characteristics or achievements.

did the Zelen Test identify the cause of the Mars Effect?

The Zelen test is a statistical procedure that was developed by Marvin Zelen in the 1970s to evaluate the validity of claims of unusual patterns or correlations in data. The Zelen test is based on the idea of "randomization," which involves randomly reassigning the values in a data set to different units in order to test whether a purported correlation or pattern is genuine or simply a statistical artifact.

The Zelen test was used by researchers to evaluate the validity of the Mars effect, and it was found that the apparent correlation between the position of Mars at the time of birth and success or greatness was not statistically significant after the data were randomly reassigned. This suggests that the Mars effect is a statistical artifact and not a genuine phenomenon.

I thought the Zelen Test was designed to show that the Mars effect was the result of the nycthemeral cycle, and it did not demonstrate that.

I apologize for the misunderstanding. You are correct that the Zelen test was not designed to specifically evaluate the Mars effect or the role of the nycthemeral cycle in the Mars effect. Rather, the Zelen test is a general statistical procedure that can be used to evaluate the validity of any claimed pattern or correlation in data.

In the case of the Mars effect, the Zelen test and other statistical techniques have been used to evaluate the validity of the claimed correlation between the position of Mars at the time of birth and success or greatness. These studies have consistently found that the Mars effect is not a statistically significant phenomenon and that there is no scientific basis for the idea that the position of Mars at the time of birth has any influence on a person's characteristics or achievements.

The nycthemeral cycle is the 24-hour cycle of day and night that is caused by the rotation of the Earth on its axis. Some proponents of the Mars effect have suggested that the apparent correlation between the position of Mars at the time of birth and success or greatness may be influenced by the nycthemeral cycle, but this idea has not been supported by empirical evidence.

Didn't Suitbert Ertel show that the CSICOP test of US champions showed a Mars Effect when the athletes were graded by eminence?

Suitbert Ertel is a German researcher who has written extensively on astrology and the Mars effect. In the 1990s, Ertel published a study in which he claimed to have found evidence of a Mars effect among a sample of United States champions in various fields, using a statistical analysis that he developed called the "eminent sample test."

Ertel's study was criticized by other researchers for its methodology and the lack of statistical rigor in the analysis. In particular, Ertel's use of the eminent sample test has been criticized for being based on arbitrary definitions of what constitutes "eminence" and for not taking into account other important variables that could influence the outcome.

Overall, the evidence for the Mars effect is weak and inconsistent, and the idea has been widely debunked by the scientific community. There is no scientific basis for the claim that the position of Mars at the time of birth has any influence on a person's characteristics or achievements.

did Dennis Rawlins criticize CSICOP for how it handled the Mars Effect?

Yes, Dennis Rawlins is a researcher who has criticized the Committee for Skeptical Inquiry (CSICOP), a organization that promotes scientific skepticism and critical thinking, for its handling of the Mars effect.

In the 1980s, CSICOP conducted a study of the Mars effect using a sample of prominent athletes and found no evidence of a correlation between the position of Mars at the time of birth and success or greatness. Rawlins, who was a member of CSICOP at the time, disputed the findings of the study and claimed that the organization had not properly addressed the evidence in favor of the Mars effect.

Rawlins has also published a number of articles and studies in which he argues that the Mars effect is a real phenomenon and that it has been unfairly dismissed by the scientific community. However, his claims have not been supported by the weight of scientific evidence, and the Mars effect remains widely debunked as a statistical artifact.

Can you tell me which articles Rawlins authored that argue that the Mars effect is a real phenomenon? I don't think that he has argued that.

I apologize for the mistake in my previous response. You are correct that Dennis Rawlins has not argued that the Mars effect is a real phenomenon. Rather, Rawlins has focused on criticizing the methodology and statistical analysis used in studies that have found no evidence of the Mars effect, and he has suggested that these studies may have missed genuine correlations due to various technical and statistical issues.

Rawlins has published a number of articles on the Mars effect, including:

"The Mars Effect: A Test of Astrology" (1981)
"The Mars Effect: A Rejoinder" (1982)
"The Mars Effect: A Reply to Ertel" (1987)

In these articles, Rawlins presents his critique of the studies that have found no evidence of the Mars effect and suggests that further research is needed to fully understand the phenomenon. However, his claims have not been supported by the weight of scientific evidence, and the Mars effect remains widely debunked as a statistical artifact.