Artix Linux Forum

Artix Linux => Package management => Topic started by: mrbrklyn on 25 April 2024, 08:21:06

Title: syslog-ng security
Post by: mrbrklyn on 25 April 2024, 08:21:06
I just ran an update and syslog-ng was one of the updated packages and it is warning that the filesystem is set to 700 and the package is 755.

It seems to be the 700 is the correct security setting.

Can anyone confirm or comment?
Title: Re: syslog-ng security
Post by: Ambie on 25 April 2024, 11:02:08
https://forum.artixlinux.org/index.php/topic,4771.0.html

TL;DR: It's not a big deal.
Title: Re: syslog-ng security
Post by: mrbrklyn on 25 April 2024, 15:05:18
I'm not convinced of that in this case.  The system logger is a huge plum for black hat attacks and it needs to be locked down for standard security.  General users should definitely not have execute permission, which is what 755 is, and it is much safer to not be readable by general users.  It might need group rw if all your loggers on in a group.  But ideally, 700 is much safer.  The first thing every exploit tries to do is remove its foot print by manipulating the system log.
Title: Re: syslog-ng security
Post by: Ambie on 25 April 2024, 15:26:20
Yes. That's why syslog-ng resets permissions to 0700 on run. And although 755 permissions in package is a kinda bug but not a big deal I guess. Also I think, to "remove footprint" and "manipulate logs" such exploit needs write permission and not just read one. And if it can write to root-owned directory then directory permissions is the least of your problems.
Title: Re: syslog-ng security
Post by: gripped on 25 April 2024, 15:41:19
General users should definitely not have execute permission, which is what 755 is
The 'execute bit' is not related to execution when used on directories. It's more of a traversal bit or entry bit.

Title: Re: syslog-ng security
Post by: mrbrklyn on 25 April 2024, 16:18:28
General users should definitely not have execute permission, which is what 755 is
The 'execute bit' is not related to execution when used on directories. It's more of a traversal bit or entry bit.




it allows for remove.  I am fairly certain of that.  You can't  write, but you can delete... which I always thought was a bad design.
Title: Re: syslog-ng security
Post by: Ambie on 25 April 2024, 18:02:11
which I always thought was a bad design.
I presume that "good design" for you would be that with some permission bit we can look into directory but we cannot delete it? There is immutable bit. But I guess we digress.
Title: Re: syslog-ng security
Post by: mrbrklyn on 25 April 2024, 18:23:23
yup - a user can look and even see the file contents in a directory (then can use the directory) but not alter it in any way.  That is a useful setting
Title: Re: syslog-ng security
Post by: gripped on 25 April 2024, 18:29:18
it allows for remove.  I am fairly certain of that.  You can't  write, but you can delete... which I always thought was a bad design.
It will only let you remove a root owned 0755 dir (lets call it test) if the user doing the removing has write access to the dir containing test.
That's my understanding of it anyway.

And I just got curious as to nomenclature. According to the chmod man page the 'execute bit' is called the 'search bit' when applied to directories. Which I'm not convinced is the greatest of names but I've learnt another thing today regardless.
Title: Re: syslog-ng security
Post by: mrbrklyn on 25 April 2024, 21:32:06
I did a test on my artix system and indeed a 755 directory say /test/
owned by root and a 755

can not remove a file from the directy unless it is owned by the user


Code: [Select]
flatbush:[ruben]:~$ ls -al  /test/test.txt 
-rwxrw-rw- 1 root root 0 Apr 25 15:23 /test/test.txt

that file can be modified by any user, but not removed

that is all at 755 on the /test directory.

I can swear I have seen different behaviors previously on diferent disto's.
Title: Re: syslog-ng security
Post by: Ambie on 26 April 2024, 07:48:46
I can swear I have seen different behaviors previously on diferent disto's.
Swear is not hard evidence, right? There is ACL (https://wiki.archlinux.org/title/Access_Control_Lists) though.