* svlogd and umask settings @ 2006-08-30 22:03 Vincent Danen 2006-09-01 17:49 ` Vincent Danen 0 siblings, 1 reply; 8+ messages in thread From: Vincent Danen @ 2006-08-30 22:03 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 1241 bytes --] I have an issue with svlogd where I need it to write files with 0640 perms, but it wants to write with 0644 perms. I tried to toss a umask call in my runscript: [root@ares apparmor.d]# cat /service/auditd/log/run #!/bin/execlineb # logging for the auditd service; unfortunately we need to run as root here # so that genprof will look at our log /bin/foreground { /usr/bin/install -m 0700 -d -o root -g root /var/log/system/audit } /bin/cd /var/log/service /bin/umask 026 /sbin/svlogd /var/log/system/audit This doesn't seem to make a difference to svlogd. Looking in the manpage, I didn't see anything about changing the permissions of files it creates. But even with the above I get: [root@ares apparmor.d]# ls -l /var/log/system/audit/ total 0 -rw-r--r-- 1 root root 0 Aug 30 16:17 current -rw------- 1 root root 0 Aug 30 16:17 lock What am I missing or do I have to change something in svlogd itself? Since Annvix is now using socklog by default, I need to make sure logs are 0640. The directory permissions are correct, but the log file permissions are not. -- {FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4} mysql> SELECT * FROM users WHERE clue > 0; Empty set (0.00sec) [-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: svlogd and umask settings 2006-08-30 22:03 svlogd and umask settings Vincent Danen @ 2006-09-01 17:49 ` Vincent Danen 2006-09-15 14:47 ` Gerrit Pape 0 siblings, 1 reply; 8+ messages in thread From: Vincent Danen @ 2006-09-01 17:49 UTC (permalink / raw) Cc: supervision [-- Attachment #1: Type: text/plain, Size: 2221 bytes --] * Vincent Danen <vdanen@linsec.ca> [2006-08-30 16:03:25 -0600]: > I have an issue with svlogd where I need it to write files with 0640 > perms, but it wants to write with 0644 perms. I tried to toss a umask > call in my runscript: > > [root@ares apparmor.d]# cat /service/auditd/log/run > #!/bin/execlineb > > # logging for the auditd service; unfortunately we need to run as root here > # so that genprof will look at our log > > /bin/foreground { /usr/bin/install -m 0700 -d -o root -g root > /var/log/system/audit } > /bin/cd /var/log/service > /bin/umask 026 > /sbin/svlogd /var/log/system/audit > > This doesn't seem to make a difference to svlogd. Looking in the > manpage, I didn't see anything about changing the permissions of files > it creates. But even with the above I get: > > [root@ares apparmor.d]# ls -l /var/log/system/audit/ > total 0 > -rw-r--r-- 1 root root 0 Aug 30 16:17 current > -rw------- 1 root root 0 Aug 30 16:17 lock > > What am I missing or do I have to change something in svlogd itself? > Since Annvix is now using socklog by default, I need to make sure logs > are 0640. The directory permissions are correct, but the log file > permissions are not. Ok, I see the problem. I see all the fchmod() calls in svlogd.c that are writing files as mode 0744 or 0644. What would be nice to see is if svlogd could be configured to accept as a config option perms for files or if it respected umask settings. As it stands right now, I'm going to have to patch svlogd.c to make it write files mode 0740 or 0640. In conjunction with stuff like socklog, this is pretty important. You never see stuff like /var/log/messages or /var/log/auth.log with such insecure permissions so it would be good if something that socklog depended on could likewise write more secure log files. Maybe a switch (like -s) to enable secure logfile writing (mode 0x40) and -ss to enable more secure logile writing (mode 0x00)? My C skills aren't overly sharp, but I'll see if I can hobble a patch together for this. -- {FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4} mysql> SELECT * FROM users WHERE clue > 0; Empty set (0.00sec) [-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: svlogd and umask settings 2006-09-01 17:49 ` Vincent Danen @ 2006-09-15 14:47 ` Gerrit Pape 2006-09-15 15:22 ` Vincent Danen 0 siblings, 1 reply; 8+ messages in thread From: Gerrit Pape @ 2006-09-15 14:47 UTC (permalink / raw) On Fri, Sep 01, 2006 at 11:49:40AM -0600, Vincent Danen wrote: > * Vincent Danen <vdanen@linsec.ca> [2006-08-30 16:03:25 -0600]: > > I have an issue with svlogd where I need it to write files with 0640 > > perms, but it wants to write with 0644 perms. I tried to toss a umask > > call in my runscript: > > This doesn't seem to make a difference to svlogd. Looking in the > > manpage, I didn't see anything about changing the permissions of files > > it creates. But even with the above I get: > > > > [root@ares apparmor.d]# ls -l /var/log/system/audit/ > > total 0 > > -rw-r--r-- 1 root root 0 Aug 30 16:17 current > > -rw------- 1 root root 0 Aug 30 16:17 lock > > > > What am I missing or do I have to change something in svlogd itself? > > Since Annvix is now using socklog by default, I need to make sure logs > > are 0640. The directory permissions are correct, but the log file > > permissions are not. > > Ok, I see the problem. I see all the fchmod() calls in svlogd.c that > are writing files as mode 0744 or 0644. What would be nice to see is if > svlogd could be configured to accept as a config option perms for files > or if it respected umask settings. As it stands right now, I'm going to > have to patch svlogd.c to make it write files mode 0740 or 0640. Yes, this is compiled in. > In conjunction with stuff like socklog, this is pretty important. You > never see stuff like /var/log/messages or /var/log/auth.log with such > insecure permissions so it would be good if something that socklog > depended on could likewise write more secure log files. Isn't it enough to set restrictive permissions on the directory? svlogd won't touch these settings. Regards, Gerrit. ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: svlogd and umask settings 2006-09-15 14:47 ` Gerrit Pape @ 2006-09-15 15:22 ` Vincent Danen 2006-09-16 9:51 ` Laurent Bercot 2006-09-18 15:18 ` Christian Holtje 0 siblings, 2 replies; 8+ messages in thread From: Vincent Danen @ 2006-09-15 15:22 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 2309 bytes --] * Gerrit Pape <pape@smarden.org> [2006-09-15 14:47:44 +0000]: > > > I have an issue with svlogd where I need it to write files with 0640 > > > perms, but it wants to write with 0644 perms. I tried to toss a umask > > > call in my runscript: > > > > This doesn't seem to make a difference to svlogd. Looking in the > > > manpage, I didn't see anything about changing the permissions of files > > > it creates. But even with the above I get: > > > > > > [root@ares apparmor.d]# ls -l /var/log/system/audit/ > > > total 0 > > > -rw-r--r-- 1 root root 0 Aug 30 16:17 current > > > -rw------- 1 root root 0 Aug 30 16:17 lock > > > > > > What am I missing or do I have to change something in svlogd itself? > > > Since Annvix is now using socklog by default, I need to make sure logs > > > are 0640. The directory permissions are correct, but the log file > > > permissions are not. > > > > Ok, I see the problem. I see all the fchmod() calls in svlogd.c that > > are writing files as mode 0744 or 0644. What would be nice to see is if > > svlogd could be configured to accept as a config option perms for files > > or if it respected umask settings. As it stands right now, I'm going to > > have to patch svlogd.c to make it write files mode 0740 or 0640. > > Yes, this is compiled in. > > > In conjunction with stuff like socklog, this is pretty important. You > > never see stuff like /var/log/messages or /var/log/auth.log with such > > insecure permissions so it would be good if something that socklog > > depended on could likewise write more secure log files. > > Isn't it enough to set restrictive permissions on the directory? svlogd > won't touch these settings. I could, yes, but it just seems wrong to me. =) I do already have restrictive settings on the parent directories, and having looked at it, it does look well enough (ie. keeps the snoopers out). I'm trying to have everything write with the correct perms, however, and not rely on other things because while svlogd may not change the perms on the parent directory, a dumb admin might and I'm aiming to protect dumb admins from themselves. -- {FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4} mysql> SELECT * FROM users WHERE clue > 0; Empty set (0.00sec) [-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: svlogd and umask settings 2006-09-15 15:22 ` Vincent Danen @ 2006-09-16 9:51 ` Laurent Bercot 2006-09-16 17:20 ` Vincent Danen 2006-09-18 15:18 ` Christian Holtje 1 sibling, 1 reply; 8+ messages in thread From: Laurent Bercot @ 2006-09-16 9:51 UTC (permalink / raw) > and I'm aiming to protect dumb admins from themselves. I don't want to start a discussion here, or sound patronizing, but might I suggest you're on a wild goose chase ? ;) Unix wasn't made to protect dumb admins from themselves. It was made to be used by people who know what they're doing. (And that's the reason why there are so many Unix problems and misconfigurations.) I have found so far that the most efficient way to write software that aims to ensure proper working and security of a Unix system is to set clear boundaries and document them: point A is the software's responsibility, point B is *your* responsibility as the admin and you should make sure it works before running the software. Anyway. Enough ranting. -- Laurent ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: svlogd and umask settings 2006-09-16 9:51 ` Laurent Bercot @ 2006-09-16 17:20 ` Vincent Danen 0 siblings, 0 replies; 8+ messages in thread From: Vincent Danen @ 2006-09-16 17:20 UTC (permalink / raw) [-- Attachment #1: Type: text/plain, Size: 2331 bytes --] * Laurent Bercot <ska-supervision@skarnet.org> [2006-09-16 11:51:09 +0200]: > > and I'm aiming to protect dumb admins from themselves. > > I don't want to start a discussion here, or sound patronizing, but > might I suggest you're on a wild goose chase ? ;) No, I don't think I am. I might be, but where's the harm, really? Other than tending to sound, as you say, patronizing, or perhaps elitist, I don't see the point in telling a user or customer what you're telling me. =) > Unix wasn't made to protect dumb admins from themselves. It was made > to be used by people who know what they're doing. (And that's the > reason why there are so many Unix problems and misconfigurations.) Absolutely. But that doesn't mean it can't be done differently, or more correctly. It certainly doesn't mean that I shouldn't bother or try and assume a holier-than-thou "if you can't figure it out you don't deserve to use it" attitude. Of course, if they bugger things up even with the little bits of properness that are implemented, it's still *their* problem (not mine), but as a Linux distributor I'm doing my part to ease things. > I have found so far that the most efficient way to write software that > aims to ensure proper working and security of a Unix system is to set > clear boundaries and document them: point A is the software's > responsibility, point B is *your* responsibility as the admin and you > should make sure it works before running the software. Sure, but I'm not coding anything. I'm packaging a Linux distribution. So setting sane defaults and whatnot is part of the "job". > Anyway. Enough ranting. Yeah, that's fine. You can rant all you like, but it doesn't much matter to me. Others might take your elitist attitude to heart, and that's fine (for some stuff I also share similar elitist attitudes), but to sit back and tell people they're not smart enough to use it so I won't bother making it any easier on them seems, well, really arrogant. But that's ok too... it is unix after all and we are, more often than not, elitist, arrogant, and better than the mindless sheep that use other operating systems. =) -- {FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4} mysql> SELECT * FROM users WHERE clue > 0; Empty set (0.00sec) [-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: svlogd and umask settings 2006-09-15 15:22 ` Vincent Danen 2006-09-16 9:51 ` Laurent Bercot @ 2006-09-18 15:18 ` Christian Holtje 2006-09-18 16:06 ` Vincent Danen 1 sibling, 1 reply; 8+ messages in thread From: Christian Holtje @ 2006-09-18 15:18 UTC (permalink / raw) Vincent Danen wrote: > * Gerrit Pape <pape@smarden.org> [2006-09-15 14:47:44 +0000]: > >>>> I have an issue with svlogd where I need it to write files with 0640 >>>> perms, but it wants to write with 0644 perms. I tried to toss a umask >>>> call in my runscript: >>>> This doesn't seem to make a difference to svlogd. Looking in the >>>> manpage, I didn't see anything about changing the permissions of files >>>> it creates. But even with the above I get: >>>> >>>> [root@ares apparmor.d]# ls -l /var/log/system/audit/ >>>> total 0 >>>> -rw-r--r-- 1 root root 0 Aug 30 16:17 current >>>> -rw------- 1 root root 0 Aug 30 16:17 lock >>>> >>>> What am I missing or do I have to change something in svlogd itself? >>>> Since Annvix is now using socklog by default, I need to make sure logs >>>> are 0640. The directory permissions are correct, but the log file >>>> permissions are not. >>> Ok, I see the problem. I see all the fchmod() calls in svlogd.c that >>> are writing files as mode 0744 or 0644. What would be nice to see is if >>> svlogd could be configured to accept as a config option perms for files >>> or if it respected umask settings. As it stands right now, I'm going to >>> have to patch svlogd.c to make it write files mode 0740 or 0640. >> Yes, this is compiled in. >> >>> In conjunction with stuff like socklog, this is pretty important. You >>> never see stuff like /var/log/messages or /var/log/auth.log with such >>> insecure permissions so it would be good if something that socklog >>> depended on could likewise write more secure log files. >> Isn't it enough to set restrictive permissions on the directory? svlogd >> won't touch these settings. > > I could, yes, but it just seems wrong to me. =) I do already have > restrictive settings on the parent directories, and having looked at it, > it does look well enough (ie. keeps the snoopers out). > > I'm trying to have everything write with the correct perms, however, and > not rely on other things because while svlogd may not change the perms > on the parent directory, a dumb admin might and I'm aiming to protect > dumb admins from themselves. I would argue that more important than the idea of protecting a sys-admin is the principal of least surprise. The sys-admin user here tried to change the mask of the log files by changing the umask. This implies that a user expects umask to be effective. On the flip side, we don't want to be _accidentally_ creating 777 files. I would suggest putting an entry in the log, upon svlog startup, that complains about possibly unsafe permissions. I wouldn't be adverse to svlog preventing umask from being less than 002, at least not without specifying a flag. Example Log message: **** SVLOG has determined that your umask (000) would make the file permissions unsafe. I'm going to override your umask to 022. If you meant for umask to be this, then please pass the option '--umask=000' to svlog. *** That would be a good user interface, I think. Ciao! -- Ninety-eight percent of the adults in this country are decent, hard-working, honest Americans. It's the other lousy two percent that get all the publicity. But then--we elected them. -- Lily Tomlin The Doctor What: Da Man http://docwhat.gerf.org/ docwhat *at* gerf *dot* org KF6VNC ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: svlogd and umask settings 2006-09-18 15:18 ` Christian Holtje @ 2006-09-18 16:06 ` Vincent Danen 0 siblings, 0 replies; 8+ messages in thread From: Vincent Danen @ 2006-09-18 16:06 UTC (permalink / raw) Cc: supervision [-- Attachment #1: Type: text/plain, Size: 3737 bytes --] * Christian Holtje <list.supervision@docwhat.gerf.org> [2006-09-18 11:18:37 -0400]: > >>>> I have an issue with svlogd where I need it to write files with 0640 > >>>> perms, but it wants to write with 0644 perms. I tried to toss a umask > >>>> call in my runscript: > >>>> This doesn't seem to make a difference to svlogd. Looking in the > >>>> manpage, I didn't see anything about changing the permissions of files > >>>> it creates. But even with the above I get: > >>>> > >>>> [root@ares apparmor.d]# ls -l /var/log/system/audit/ > >>>> total 0 > >>>> -rw-r--r-- 1 root root 0 Aug 30 16:17 current > >>>> -rw------- 1 root root 0 Aug 30 16:17 lock > >>>> > >>>> What am I missing or do I have to change something in svlogd itself? > >>>> Since Annvix is now using socklog by default, I need to make sure logs > >>>> are 0640. The directory permissions are correct, but the log file > >>>> permissions are not. > >>> Ok, I see the problem. I see all the fchmod() calls in svlogd.c that > >>> are writing files as mode 0744 or 0644. What would be nice to see is if > >>> svlogd could be configured to accept as a config option perms for files > >>> or if it respected umask settings. As it stands right now, I'm going to > >>> have to patch svlogd.c to make it write files mode 0740 or 0640. > >> Yes, this is compiled in. > >> > >>> In conjunction with stuff like socklog, this is pretty important. You > >>> never see stuff like /var/log/messages or /var/log/auth.log with such > >>> insecure permissions so it would be good if something that socklog > >>> depended on could likewise write more secure log files. > >> Isn't it enough to set restrictive permissions on the directory? svlogd > >> won't touch these settings. > > > > I could, yes, but it just seems wrong to me. =) I do already have > > restrictive settings on the parent directories, and having looked at it, > > it does look well enough (ie. keeps the snoopers out). > > > > I'm trying to have everything write with the correct perms, however, and > > not rely on other things because while svlogd may not change the perms > > on the parent directory, a dumb admin might and I'm aiming to protect > > dumb admins from themselves. > > I would argue that more important than the idea of protecting a > sys-admin is the principal of least surprise. The sys-admin user > here tried to change the mask of the log files by changing the umask. > > This implies that a user expects umask to be effective. On the flip > side, we don't want to be _accidentally_ creating 777 files. Yup, true. But svlogd would need to be aware of umask settings... right now it doesn't care and writes files mode 0744 or 0644; either way it's not creating 0777 files nor is it even bothering to look at the umask. > I would suggest putting an entry in the log, upon svlog startup, > that complains about possibly unsafe permissions. I wouldn't be > adverse to svlog preventing umask from being less than 002, at least > not without specifying a flag. > > Example Log message: > **** SVLOG has determined that your umask (000) would make the > file permissions unsafe. I'm going to override your umask to 022. > If you meant for umask to be this, then please pass the option > '--umask=000' to svlog. *** > > That would be a good user interface, I think. It would first need svlogd caring about umask settings... =) But I agree. I'd like to see either a switch to specify log perms or svlogd using umask settings (and doing the sanity check you note above). -- {FEE30AD4 : 7F6C A60C 06C2 4811 FA1C A2BC 2EBC 5E32 FEE3 0AD4} mysql> SELECT * FROM users WHERE clue > 0; Empty set (0.00sec) [-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --] ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2006-09-18 16:06 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2006-08-30 22:03 svlogd and umask settings Vincent Danen 2006-09-01 17:49 ` Vincent Danen 2006-09-15 14:47 ` Gerrit Pape 2006-09-15 15:22 ` Vincent Danen 2006-09-16 9:51 ` Laurent Bercot 2006-09-16 17:20 ` Vincent Danen 2006-09-18 15:18 ` Christian Holtje 2006-09-18 16:06 ` Vincent Danen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).