svlogd and umask settings

svlogd and umask settings

[Vincent Danen]

[-- 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 --]

Re: svlogd and umask settings

[Vincent Danen]

[-- 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 --]

Re: svlogd and umask settings

[Gerrit Pape]

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.

Re: svlogd and umask settings

[Vincent Danen]

[-- 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 --]

Re: svlogd and umask settings

[Laurent Bercot]

> 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

Re: svlogd and umask settings

[Vincent Danen]

[-- 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 --]

Re: svlogd and umask settings

[Christian Holtje]

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

Re: svlogd and umask settings

[Vincent Danen]

[-- 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 --]