Syslogd: Adding log sockets that are only writeable by a single group
I'm making some modifications to syslogd/syslog so that I can control access to log sockets and have a set of high integrity log files that didn't receive logs from world-writable log sockets. Briefly, this means: - syslogd needs to be able to optionally apply groups to log sockets - syslogd/syslog.conf needs to allow users to filter logs based on input socket - openlog() needs to attempt to open /dev/log__primarygroup first, falling back to /dev/log So far, I've modified syslogd.c so that each of the sockets specified with the -a option can optionally be associated with a group that is given write access. On the command line, it would look like this: syslogd -a /dev/log__sshd:_sshd -a /dev/log__www:_www -a /dev/log__users:users Next, I would like to add the ability to filter based on input socket to syslog.conf, but I'm not sure what the best place to put that functionality might be. Currently, I'm considering something like: !prog:/dev/log__proggroup Does anyone have some comments or suggestions for this concept? Thanks, Eric
Re: Syslogd: Adding log sockets that are only writeable by a single group
On Sat, Feb 12, 2011 at 9:49 AM, Eric airu...@gmail.com wrote: I'm making some modifications to syslogd/syslog so that I can control access to log sockets and have a set of high integrity log files that didn't receive logs from world-writable log sockets. Briefly, this means: It means you put the socket into a directory with the appropriate permissions. Sockets don't have permissions.
Re: Syslogd: Adding log sockets that are only writeable by a single group
On Sat, Feb 12, 2011 at 12:00 PM, Ted Unangst ted.unan...@gmail.com wrote: On Sat, Feb 12, 2011 at 9:49 AM, Eric airu...@gmail.com wrote: I'm making some modifications to syslogd/syslog so that I can control access to log sockets and have a set of high integrity log files that didn't receive logs from world-writable log sockets. Briefly, this means: It means you put the socket into a directory with the appropriate permissions. Sockets don't have permissions. I just tested it: sockets have permissions on OpenBSD and they are enforced.
Re: Syslogd: Adding log sockets that are only writeable by a single group
On Sat, Feb 12, 2011 at 12:53:47PM -0500, Eric wrote: On Sat, Feb 12, 2011 at 12:00 PM, Ted Unangst ted.unan...@gmail.com wrote: On Sat, Feb 12, 2011 at 9:49 AM, Eric airu...@gmail.com wrote: I'm making some modifications to syslogd/syslog so that I can control access to log sockets and have a set of high integrity log files that didn't receive logs from world-writable log sockets. Briefly, this means: It means you put the socket into a directory with the appropriate permissions. Sockets don't have permissions. I just tested it: sockets have permissions on OpenBSD and they are enforced. Yes, originally permissions on sockets were not enforced. But creating a socket and setting permissions on it is still subject to race conditions. So in practice you'll need dirs. -Otto
Re: Syslogd: Adding log sockets that are only writeable by a single group
On Sat, Feb 12, 2011 at 02:22:21PM -0500, Eric wrote:
On Sat, Feb 12, 2011 at 1:56 PM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Feb 12, 2011 at 12:53:47PM -0500, Eric wrote:
On Sat, Feb 12, 2011 at 12:00 PM, Ted Unangst ted.unan...@gmail.com
wrote:
On Sat, Feb 12, 2011 at 9:49 AM, Eric airu...@gmail.com wrote:
I'm making some modifications to syslogd/syslog so that I can control
access
to log sockets and have a set of high integrity log files that didn't
receive logs
from world-writable log sockets. ?Briefly, this means:
It means you put the socket into a directory with the appropriate
permissions. ?Sockets don't have permissions.
I just tested it: sockets have permissions on OpenBSD and they are
enforced.
Yes, originally permissions on sockets were not enforced. But creating
a socket and setting permissions on it is still subject to race
conditions. So in practice you'll need dirs.
? ? ? ?-Otto
Syslogd already uses socket permissions to protect its control socket:
if (ctlsock_path != NULL) {
fd = unix_socket(ctlsock_path, SOCK_STREAM, 0600);
if (fd != -1) {
Should I patch it so that the control socket is placed in a directory
with appropriate permissions?
Probably not, unix_socket() seems to do it right and socket ownership
doesn't come into play.
-Otto
Re: Syslogd: Adding log sockets that are only writeable by a single group
On Sat, Feb 12, 2011 at 1:56 PM, Otto Moerbeek o...@drijf.net wrote:
On Sat, Feb 12, 2011 at 12:53:47PM -0500, Eric wrote:
On Sat, Feb 12, 2011 at 12:00 PM, Ted Unangst ted.unan...@gmail.com
wrote:
On Sat, Feb 12, 2011 at 9:49 AM, Eric airu...@gmail.com wrote:
I'm making some modifications to syslogd/syslog so that I can control
access
to log sockets and have a set of high integrity log files that didn't
receive logs
from world-writable log sockets. Briefly, this means:
It means you put the socket into a directory with the appropriate
permissions. Sockets don't have permissions.
I just tested it: sockets have permissions on OpenBSD and they are
enforced.
Yes, originally permissions on sockets were not enforced. But creating
a socket and setting permissions on it is still subject to race
conditions. So in practice you'll need dirs.
-Otto
Syslogd already uses socket permissions to protect its control socket:
if (ctlsock_path != NULL) {
fd = unix_socket(ctlsock_path, SOCK_STREAM, 0600);
if (fd != -1) {
Should I patch it so that the control socket is placed in a directory
with appropriate permissions?
Re: Strange pf match
On 2011-02-12, m mutimir2...@yahoo.com wrote:
please take a look and tell if I'm missing something or is this a serious bug?
#tcpdump -n -e -ttt -i pflog0
tcpdump: listening on pflog0, link-type PFLOG
Feb 12 15:40:18.181584 rule 704/(match) pass in on vlan2: 10.100.100.55.49747
10.7.13.115.25: S 1349727012:1349727012(0) win 5840 mss
1460,sackOK,timestamp 973726855[|tcp] (DF) [tos 0x10]
# pfctl -vvsr | grep @704
@704 pass in log quick on vlan2 inet proto tcp from 10.100.100.0/24 to
10.10.4.114 - 10.10.4.116 flags S/SA keep state
So, the rule with the IP Range matches wrong dst address. If I rewrite a rule
without using a range, then it works OK.
OpenBSD 4.7 GENERIC i386
Thank You very much.
Confirmed, address ranges are broken on little-endian and it's
still present in -current.
I've tested this on v4/v6 LE, baking a BE kernel now. Any ok's?
Index: pf.c
===
RCS file: /cvs/src/sys/net/pf.c,v
retrieving revision 1.725
diff -u -p -r1.725 pf.c
--- pf.c6 Feb 2011 23:12:12 - 1.725
+++ pf.c12 Feb 2011 21:37:44 -
@@ -2180,8 +2180,8 @@ pf_match_addr_range(struct pf_addr *b, s
switch (af) {
#ifdef INET
case AF_INET:
- if ((a-addr32[0] b-addr32[0]) ||
- (a-addr32[0] e-addr32[0]))
+ if ((ntohl(a-addr32[0]) ntohl(b-addr32[0])) ||
+ (ntohl(a-addr32[0]) ntohl(e-addr32[0])))
return (0);
break;
#endif /* INET */
@@ -2191,15 +2191,15 @@ pf_match_addr_range(struct pf_addr *b, s
/* check a = b */
for (i = 0; i 4; ++i)
- if (a-addr32[i] b-addr32[i])
+ if (ntohl(a-addr32[i]) ntohl(b-addr32[i]))
break;
- else if (a-addr32[i] b-addr32[i])
+ else if (ntohl(a-addr32[i]) ntohl(b-addr32[i]))
return (0);
/* check a = e */
for (i = 0; i 4; ++i)
- if (a-addr32[i] e-addr32[i])
+ if (ntohl(a-addr32[i]) ntohl(e-addr32[i]))
break;
- else if (a-addr32[i] e-addr32[i])
+ else if (ntohl(a-addr32[i]) ntohl(e-addr32[i]))
return (0);
break;
}
Re: cwm crashes on Linux when combining grouponly/movetogroup
Catching up on this bug, which has hit some other users I know now as well.
Christian Neukirchen chneukirc...@gmail.com writes:
I found this key sequence to crash cwm on Linux in CVS HEAD:
Minimal .cwmrc:
bind C-i grouponly2
bind CS-i movetogroup2
Run cwm, open a window (say xterm), press C-i, press CS-i, press C-i.
cwm crashes on Linux with this backtrace:
#0 0x76027595 in raise () from /lib/libc.so.6
#1 0x76028a16 in abort () from /lib/libc.so.6
#2 0x760612cb in ?? () from /lib/libc.so.6
#3 0x76066676 in ?? () from /lib/libc.so.6
#4 0x00408a72 in group_show (sc=0x625d80, gc=0x625f38) at
group.c:135
#5 0x00408e76 in group_only (sc=0x625d80, idx=4) at group.c:302
#6 0x004084e7 in xev_handle_keypress (ee=0x7fffde00)
at xevents.c:335
#7 0x004087dd in xev_loop () at xevents.c:446
#8 0x00403969 in main (argc=value optimized out,
argv=value optimized out) at calmwm.c:92
Analyzing group_show, I found out:
winlist = (Window *) xcalloc(sizeof(*winlist), (gc-highstack + 1));
...
TAILQ_FOREACH(cc, gc-clients, group_entry) {
winlist[gc-highstack - cc-stackingorder] = cc-win;
client_unhide(cc);
}
For some reason cc-stackingorder is bigger than gc-highstack (which is
0 in above use case), thus the assignment writes to a negative address
relative to winlist. I can reproduce that on OpenBSD 4.8/cwm HEAD as
well, it just doesn't crash there because the heap corruption goes
undetected.
I hope this helps debugging, I don't fully understand the code yet.
Breakpoint 1, group_show (sc=0x624e70, gc=0x624f98) at group.c:118
118 winlist[gc-highstack - cc-stackingorder] = cc-win;
(gdb) p gc-highstack
$5 = 0
(gdb) p cc-stackingorder
$6 = 1
--
Christian Neukirchen chneukirc...@gmail.com http://chneukirchen.org
Re: cwm crashes on Linux when combining grouponly/movetogroup
On Sun, 13 Feb 2011, Christian Neukirchen wrote:
Catching up on this bug, which has hit some other users I know now as well.
For some reason cc-stackingorder is bigger than gc-highstack (which is
0 in above use case), thus the assignment writes to a negative address
relative to winlist. I can reproduce that on OpenBSD 4.8/cwm HEAD as
easiest fix is to apply a liberal dose of the big hammer:
Index: group.c
===
RCS file: /cvs/xenocara/app/cwm/group.c,v
retrieving revision 1.48
diff -u group.c
--- group.c 25 Sep 2010 20:01:27 - 1.48
+++ group.c 13 Feb 2011 02:07:37 -
@@ -108,6 +108,11 @@
u_inti;
int lastempty = -1;
+ gc-highstack = 0;
+ TAILQ_FOREACH(cc, gc-clients, group_entry) {
+ if (cc-stackingorder gc-highstack)
+ gc-highstack = cc-stackingorder;
+ }
winlist = (Window *) xcalloc(sizeof(*winlist), (gc-highstack + 1));
/*
Re: Syslogd: Adding log sockets that are only writeable by a single group
On Sat, Feb 12, 2011 at 10:56 AM, Otto Moerbeek o...@drijf.net wrote: On Sat, Feb 12, 2011 at 9:49 AM, Eric airu...@gmail.com wrote: I'm making some modifications to syslogd/syslog so that I can control access to log sockets and have a set of high integrity log files that didn't receive logs from world-writable log sockets. Briefly, this means: ... Yes, originally permissions on sockets were not enforced. But creating a socket and setting permissions on it is still subject to race conditions. So in practice you'll need dirs. ...and directories solve the group ownership too: a new UNIX domain socket will inherit the group of the directory it's created in. So syslogd doesn't need any special code for handling the creation of the socket, you just need the code to filter based on source socket and the code to have syslog() go to an alternate socket. Regarding the latter: if you're intending that this should affect all programs without any changes to the program themselves, then this will require much care and verification that it doesn't bloat everything. Consider that *every* C program on OpenBSD pulls in syslog_r() to support the stack-protector check code. If that starts pulling the NIS code for getgrgid() to do the gid - name mapping to find the syslog socket, then many binaries will grow. That code would _have_ to be excluded from the libc used in ramdisk builds! Philip Guenther
