Re: securelevel 1

On Fri, Oct 27, 2023 at 03:34:28AM +0100, void wrote:
> On Thu, Oct 26, 2023 at 11:36:22PM +0200, Dag-Erling Smørgrav wrote:
> > void <void@f-m.fm> writes:
> > > In order to accomplish what I'd like, I understand that I'd need to set +schg
> > > on the individual logs, then set the securelevel afterwards and reboot.
> > 
> > If you set the log file +schg, it can't be written to at all.  That's
> > obviously not what you want.
> 
> Yes, I'm sorry; I meant to type +sappnd
> 
> > If you set it +sappnd, it can be written to, and newsyslog will be able
> > to rotate it; an attacker with superuser privileges will also be able to
> > replace it with a doctored file.
> 
> Yes. But if sappend is set on the required files, and then securelevel=1
> is set, then nothing can change the flag while the system is multiuser.
> That is, if I'm understanding correctly?
> 
> So, on such a system, if I understand correctly, newsyslog would need to be
> turned off.

newsyslog does not need to change the file; it renames the file, then
it tells syslog to start a new one (one that does not exist until that
point in time), and then newsyslog may also read the renamed file,
compress the data, write it to yet another new file, etc.

So setting +sappnd on a logfile should not prevent newsyslog from
processing it. However, the fact that the file is renamed and
a brand new one is created in its place probably means that
the new logfile will *not* have the +sappnd flag set.

G'luck,
Peter

-- 
Peter Pentchev  roam@ringlet.net roam@debian.org pp@storpool.com
PGP key:        http://people.FreeBSD.org/~roam/roam.key.asc
Key fingerprint 2EE7 A7A5 17FC 124C F115  C354 651E EFB0 2527 DF13