Mailing List Archive

On Tue, 18 Nov 2008, Don Jackson wrote:

> I had the following questions:
>
> Would it be possible (optionally) to have rsyslogd chroot to a
> particular directory on startup?
> That seems the safest. One could configure a disk partition for log
> messages, configure rsyslogd to log there,

chroot doesn't help. if you have rsyslog set to log to a seperate
partition it can only fill that partition, but it can fill _all of that
partition even if you chroot into a subdirectory on that partition.

> and also chroot to a directory on that partition, so if the rsyslogd
> process itself is compromised,
> it can't do other damage.

that gives you protection if you are receiving logs from the network, but
if you are receiving logs from /dev/log (local logs) you can't go into a
chroot effectivly

> There must be a way to have a daemon run as a non-root user, and also
> to open ports < 1024.
> This seems to be done all the time on *bsd machines:

the POSIX standard still calls for ports < 1024 to require root to bind to
them, different systems have different ways to be non-compliant with the
standard and let you do so anyway. what OS are you using?

David Lang

> # ps -aux
> USER PID %CPU %MEM VSZ RSS TT STAT STARTED TIME
> COMMAND
> root 1 0.0 0.0 428 356 ?? Is Thu02PM 0:00.01 /
> sbin/init
> _dhcp 22078 0.0 0.0 396 432 ?? Is Thu03PM 0:00.01
> dhclient: bge0 (dhclient)
> _syslogd 27943 0.0 0.0 452 812 ?? S Thu03PM 0:00.19
> syslogd -a /var/empty/dev/log
>
> I'm not sure how this is done, but it looks like chroot also supports
> changing the userid...
>
> Just some thoughts,
>
> Best regards,
>
> Don
>
>
>
>
>
>
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On Tue, Nov 18, 2008 at 4:10 PM, <david@lang.hm> wrote:
> On Tue, 18 Nov 2008, Don Jackson wrote:
>
>> I had the following questions:
>>
>> Would it be possible (optionally) to have rsyslogd chroot to a
>> particular directory on startup?
>> That seems the safest. One could configure a disk partition for log
>> messages, configure rsyslogd to log there,
>
> chroot doesn't help. if you have rsyslog set to log to a seperate
> partition it can only fill that partition, but it can fill _all of that
> partition even if you chroot into a subdirectory on that partition.

Yes, but chrooting precludes any possibility of a rogue syslog agent
filling up /other/ partitions. In the event that a security compromise
were found in the rsyslogd service itself, it also confines an
attacker's damage to the chrooted environment. Paired with non-root
privileges, that's decent insurance against a full-on machine ownage.


>> and also chroot to a directory on that partition, so if the rsyslogd
>> process itself is compromised,
>> it can't do other damage.
>
> that gives you protection if you are receiving logs from the network, but
> if you are receiving logs from /dev/log (local logs) you can't go into a
> chroot effectivly
>
>> There must be a way to have a daemon run as a non-root user, and also
>> to open ports < 1024.
>> This seems to be done all the time on *bsd machines:
>
> the POSIX standard still calls for ports < 1024 to require root to bind to
> them, different systems have different ways to be non-compliant with the
> standard and let you do so anyway. what OS are you using?

OpenBSD has solved problems like this with their own daemons by
following two (general) stages of startup:

- Privileged, where the daemon reads its config file and opens the
necessary sockets (but doesn't yet listen on them). It then chroots
itself and drops its privileges:
- Unprivileged, where the daemon begins communication with the rest
of the environment and performing whatever job is required of it

For a concise discussion of how this applies to Apache (the best
explanation I've found in their docs), see:
http://www.openbsd.org/faq/faq10.html#httpdchroot

-HKS
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On Nov 18, 2008, at 1:10 PM, david@lang.hm wrote:

> On Tue, 18 Nov 2008, Don Jackson wrote:
>
>> I had the following questions:
>>
>> Would it be possible (optionally) to have rsyslogd chroot to a
>> particular directory on startup?
>> That seems the safest. One could configure a disk partition for log
>> messages, configure rsyslogd to log there,
>
> chroot doesn't help. if you have rsyslog set to log to a seperate
> partition it can only fill that partition, but it can fill _all of
> that
> partition even if you chroot into a subdirectory on that partition.

Agree that file systems or partitions can get filled up no matter what
you do.
But it seems to me the safest thing to do is to enable rsyslog to be
configured to
use a specific file system on a dedicated partition, and then always
monitor that.
Clearly that is possible with rsyslog now, but chrooting would make
this even more restrictive/secure.

If the (r)syslog clients are also using rsyslog, then they could be
configured for reliable delivery,
and queue log msgs in the event the rsyslog "server" gets hosed,so one
you fixed your rsyslog server,
they would then be able to deliver their logs.

Seems like that would be the best overall approach.

>
>> and also chroot to a directory on that partition, so if the rsyslogd
>> process itself is compromised,
>> it can't do other damage.
>
> that gives you protection if you are receiving logs from the
> network, but
> if you are receiving logs from /dev/log (local logs) you can't go
> into a
> chroot effectivly

Protecting the "server" from attacks from networked clients seems like
a good idea.

To answer your later question, I use OpenBSD a lot.
Here is how the stock syslogd on OpenBSD provides a /dev/log for each
chrooted app:

NAME
syslogd - log systems messages

SYNOPSIS
syslogd [-dnu] [-a path] [-f config_file] [-m mark_interval]
[-p log_socket] [-s reporting_socket]

DESCRIPTION
syslogd reads and logs messages to the system console, log
files, pipes
to other programs, other machines and/or users as specified by
its con-
figuration file.

The options are as follows:

-a path
Specify a location where syslogd should place an
additional log
socket. Up to about 20 additional logging sockets can
be speci-
fied. The primary use for this is to place additional
log sock-
ets in /dev/log of various chroot filespaces.

So you can arrange for each chroot'ed application to have it's own
copy of /dev/log in its chroot.

It looks like syslogd on OpenBSD itself doesn't chroot. I am still
thinking it might be possible to do so (see below), but maybe I am
totally wrong about this.

>
>> There must be a way to have a daemon run as a non-root user, and also
>> to open ports < 1024.
>> This seems to be done all the time on *bsd machines:
>
> the POSIX standard still calls for ports < 1024 to require root to
> bind to
> them, different systems have different ways to be non-compliant with
> the
> standard and let you do so anyway. what OS are you using?

Sorry, I was not being clear nor accurate here.

What I meant to say was, OK, start up as root, open the resources you
need, and then chroot, both to change your userid to something that is
non-root ( user _rsyslog ?), and also
to put rsyslog into a restricted subset file system. Could you not
open up the network ports needed, and also /dev/log (for the benefit
of apps running on that machine that will
write there?) before the call to chroot?

If not, it looks like what syslogd on OpenBSD does is separate itself
into to processes, the main process runs as root, and then it spawns a
child that runs as user _syslogd,
it is this child process that listens to log sockets, while the parent
process gives the child access to write log files.

I'm just brainstorming here. Perhaps what I am thinking is not
possible.

Don


_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On Tue, 18 Nov 2008, (private) HKS wrote:

> On Tue, Nov 18, 2008 at 4:10 PM, <david@lang.hm> wrote:
>> On Tue, 18 Nov 2008, Don Jackson wrote:
>>
>>> I had the following questions:
>>>
>>> Would it be possible (optionally) to have rsyslogd chroot to a
>>> particular directory on startup?
>>> That seems the safest. One could configure a disk partition for log
>>> messages, configure rsyslogd to log there,
>>
>> chroot doesn't help. if you have rsyslog set to log to a seperate
>> partition it can only fill that partition, but it can fill _all of that
>> partition even if you chroot into a subdirectory on that partition.
>
> Yes, but chrooting precludes any possibility of a rogue syslog agent
> filling up /other/ partitions. In the event that a security compromise
> were found in the rsyslogd service itself, it also confines an
> attacker's damage to the chrooted environment. Paired with non-root
> privileges, that's decent insurance against a full-on machine ownage.

true, but that's a very different problem than the one that Don quoted in
his message

>>> and also chroot to a directory on that partition, so if the rsyslogd
>>> process itself is compromised,
>>> it can't do other damage.
>>
>> that gives you protection if you are receiving logs from the network, but
>> if you are receiving logs from /dev/log (local logs) you can't go into a
>> chroot effectivly
>>
>>> There must be a way to have a daemon run as a non-root user, and also
>>> to open ports < 1024.
>>> This seems to be done all the time on *bsd machines:
>>
>> the POSIX standard still calls for ports < 1024 to require root to bind to
>> them, different systems have different ways to be non-compliant with the
>> standard and let you do so anyway. what OS are you using?
>
> OpenBSD has solved problems like this with their own daemons by
> following two (general) stages of startup:
>
> - Privileged, where the daemon reads its config file and opens the
> necessary sockets (but doesn't yet listen on them). It then chroots
> itself and drops its privileges:
> - Unprivileged, where the daemon begins communication with the rest
> of the environment and performing whatever job is required of it
>
> For a concise discussion of how this applies to Apache (the best
> explanation I've found in their docs), see:
> http://www.openbsd.org/faq/faq10.html#httpdchroot

Yes, many applications drop privilages (and optionally chroot) after
starting up.

I suspect that changing rsyslog to do this would be a fair bit of work
(among other things it can't do a full restart without full privilages, so
the historic HUP behavior couldn't work)

David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On Tue, 18 Nov 2008, Don Jackson wrote:

> On Nov 18, 2008, at 1:10 PM, david@lang.hm wrote:
>
>> On Tue, 18 Nov 2008, Don Jackson wrote:
>>
>>
>>> and also chroot to a directory on that partition, so if the rsyslogd
>>> process itself is compromised,
>>> it can't do other damage.
>>
>> that gives you protection if you are receiving logs from the
>> network, but
>> if you are receiving logs from /dev/log (local logs) you can't go
>> into a
>> chroot effectivly
>
> Protecting the "server" from attacks from networked clients seems like
> a good idea.
>
> To answer your later question, I use OpenBSD a lot.
> Here is how the stock syslogd on OpenBSD provides a /dev/log for each
> chrooted app:

the issue isn't providing a /dev/log for each chroot app, that can be done
easily from a syslogd that's not in the chroot by opening additional
pipes, the problem is that if the syslogd itself is inside a chroot it
cannot open anything _outside_ of that chroot, so it can't provide the
/dev/log device for the main system.

and you don't want to open that before you go into the chroot becouse one
of the ways to break out of a chroot involves having a file handle open to
something outside of the chroot.

>>> There must be a way to have a daemon run as a non-root user, and also
>>> to open ports < 1024.
>>> This seems to be done all the time on *bsd machines:
>>
>> the POSIX standard still calls for ports < 1024 to require root to
>> bind to
>> them, different systems have different ways to be non-compliant with
>> the
>> standard and let you do so anyway. what OS are you using?
>
> Sorry, I was not being clear nor accurate here.
>
> What I meant to say was, OK, start up as root, open the resources you
> need, and then chroot, both to change your userid to something that is
> non-root ( user _rsyslog ?), and also
> to put rsyslog into a restricted subset file system. Could you not
> open up the network ports needed, and also /dev/log (for the benefit
> of apps running on that machine that will
> write there?) before the call to chroot?

changing the userid will work, doing a chroot will not.

> If not, it looks like what syslogd on OpenBSD does is separate itself
> into to processes, the main process runs as root, and then it spawns a
> child that runs as user _syslogd,
> it is this child process that listens to log sockets, while the parent
> process gives the child access to write log files.

rsyslog is multi-threaded, not multi-process. all the threads have access
to everything that any one thread has access to, so it wouldn't help to
seperate things out without serious surgery to rsyslog.

you could do something like have one copy of rsyslog running inside a
chroot, and another one running outside the chroot with the one outside
the chroot not listening to the network but forwarding everything it
receives to the one inside the chroot.

this may require a little bit of work to make work (depending on how
outbound network connections are made from rsyslog)

David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

FWIW, while I believe this discussion is relevant and the security
changes proposed are important, I don't see this as a high priority
feature. The scripting language/syntax, greater performance, continued
stability enhancements, and true RELP support are all far more
important. As far as security goes, I would much rather see two-way
host authentication than a chroot/unprivilieged framework implemented.

Of course, all of the above would be just fine with me.

-HKS
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

Hi HKS,

just one point for now:

On Tue, 2008-11-18 at 17:29 -0500, (private) HKS wrote:
> important. As far as security goes, I would much rather see two-way
> host authentication than a chroot/unprivilieged framework implemented.

Two-way host authentication is available in the stable branch since
3.20.0. This is done by configuring the proper certficate settings in
TLS mode. As syslog-TLS will soon turn into a full-blown RFC, I expect
to see interoperable implementations in the not so distant future.

Rainer

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of david@lang.hm
> Sent: Tuesday, November 18, 2008 11:07 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslogd security questions/comments
[snip]

> Yes, many applications drop privilages (and optionally chroot) after
> starting up.
>
> I suspect that changing rsyslog to do this would be a fair bit of work
> (among other things it can't do a full restart without full
privilages,
> so
> the historic HUP behavior couldn't work)

Yes, the traditional HUP behavior is simply incompatible with dropping
privileges. But I assume that someone who configures rsyslogd in such a
way knows what he does and thus changes config-reload scripts away from
HUP to a real reload.

Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

Hi all,

So, let me use this reply as a warp-up of my thoughts. Basically, I
agree to HKS argument. I also agree to David Lang's argument that some
degree of design change would be necessary to get the requested features
done 100% correct.

But, of course, it all depends on the effort required. And more security
is always welcome. So I took time out today to think about the options
and experiment a bit. I came to the conclusion that some improvement can
probably be made in short time. I experimentally implemented a new
$PrivDropToUser config directive, which basically issues a setuid() call
with the user in question. It is far from being bullet-proof and will
never be totally save without architecture changes. But I think it still
can considerably improve security and when we can achieve this with a
few hours of work, it's probably worth the effort (a bit more work would
improve its security, but I don't do this unless I get feedback it makes
sense at all).

HOWEVER, there are also some things that simply don't work out. For
example, imklog reads the proc file system under Linux and, even though
it is opened as root, these reads fail after dropping to another user.
There may be other issues, I have not further investigated that.

I have created a bugzilla enhancement request for it:

http://bugzilla.adiscon.com/show_bug.cgi?id=105

You may want to subscribe to that bug for updates.

The experimental code is available here:

http://git.adiscon.com/?p=rsyslog.git;a=shortlog;h=refs/heads/droppriv

I would appreciate feedback

a) on the general issue
b) on the experimental code itself

Many thanks,
Rainer

On Tue, 2008-11-18 at 17:29 -0500, (private) HKS wrote:
> FWIW, while I believe this discussion is relevant and the security
> changes proposed are important, I don't see this as a high priority
> feature. The scripting language/syntax, greater performance, continued
> stability enhancements, and true RELP support are all far more
> important. As far as security goes, I would much rather see two-way
> host authentication than a chroot/unprivilieged framework implemented.
>
> Of course, all of the above would be just fine with me.
>
> -HKS
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

2008/11/19 Rainer Gerhards <rgerhards@hq.adiscon.com>:
> Hi all,
>
> So, let me use this reply as a warp-up of my thoughts. Basically, I
> agree to HKS argument. I also agree to David Lang's argument that some
> degree of design change would be necessary to get the requested features
> done 100% correct.
>
> But, of course, it all depends on the effort required. And more security
> is always welcome. So I took time out today to think about the options
> and experiment a bit. I came to the conclusion that some improvement can
> probably be made in short time. I experimentally implemented a new
> $PrivDropToUser config directive, which basically issues a setuid() call
> with the user in question. It is far from being bullet-proof and will
> never be totally save without architecture changes. But I think it still
> can considerably improve security and when we can achieve this with a
> few hours of work, it's probably worth the effort (a bit more work would
> improve its security, but I don't do this unless I get feedback it makes
> sense at all).
>
> HOWEVER, there are also some things that simply don't work out. For
> example, imklog reads the proc file system under Linux and, even though
> it is opened as root, these reads fail after dropping to another user.
> There may be other issues, I have not further investigated that.

/dev/klog could be made accessible via an ACL or a separate group.
(e.g. the init script of the distro could chgrp or setfacl /dev/klog).
Distros will also have to make sure, that the rsyslog daemon has write
access to /var/log (or wherever they put their log files by default,
but that is easily solvable too).

More tricky will be the already mentioned opening of privileged ports I think.

Cheers,
Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

2008/11/19 Michael Biebl <mbiebl@gmail.com>:

>
> /dev/klog could be made accessible via an ACL or a separate group.
^^^^^^^^^^^^
Argh, /proc/kmsg, I mean.


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

Hi Michael,

> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of Michael Biebl
> Sent: Wednesday, November 19, 2008 1:53 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslogd security questions/comments
>
> 2008/11/19 Rainer Gerhards <rgerhards@hq.adiscon.com>:
> > Hi all,
> >
> > So, let me use this reply as a warp-up of my thoughts. Basically, I
> > agree to HKS argument. I also agree to David Lang's argument that
> some
> > degree of design change would be necessary to get the requested
> features
> > done 100% correct.
> >
> > But, of course, it all depends on the effort required. And more
> security
> > is always welcome. So I took time out today to think about the
> options
> > and experiment a bit. I came to the conclusion that some improvement
> can
> > probably be made in short time. I experimentally implemented a new
> > $PrivDropToUser config directive, which basically issues a setuid()
> call
> > with the user in question. It is far from being bullet-proof and
will
> > never be totally save without architecture changes. But I think it
> still
> > can considerably improve security and when we can achieve this with
a
> > few hours of work, it's probably worth the effort (a bit more work
> would
> > improve its security, but I don't do this unless I get feedback it
> makes
> > sense at all).
> >
> > HOWEVER, there are also some things that simply don't work out. For
> > example, imklog reads the proc file system under Linux and, even
> though
> > it is opened as root, these reads fail after dropping to another
> user.
> > There may be other issues, I have not further investigated that.
>
> /dev/klog could be made accessible via an ACL or a separate group.
> (e.g. the init script of the distro could chgrp or setfacl /dev/klog).
> Distros will also have to make sure, that the rsyslog daemon has write
> access to /var/log (or wherever they put their log files by default,
> but that is easily solvable too).
>
> More tricky will be the already mentioned opening of privileged ports
I
> think.

The experimental code handles that. It drops privileges after processing
the config file. There is a window of insecurity between when the
listeners start and the privileges are dropped, and that can not be
solved without an architecture change. But in essence, the "port open"
problem is solved (of course, HUP will always be of non-restart type). I
think security is improved even with this Window of insecurity, so if
the rest works OK, I would consider the new code a valuable addition.

Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

2008/11/19 Michael Biebl <mbiebl@gmail.com>:
> 2008/11/19 Michael Biebl <mbiebl@gmail.com>:
>
>>
>> /dev/klog could be made accessible via an ACL or a separate group.
> ^^^^^^^^^^^^
> Argh, /proc/kmsg, I mean.

Looks like one can't set an ACL on a procfs unfortunately.

Michael


--
Why is it that all of the instruments seeking intelligent life in the
universe are pointed away from Earth?
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

An out-of-process implementation for the plugins would solve all such
issues. But that takes time... A work-around may be to run two rsyslogd
processes concurrently. Definitely not a mainstream or default config,
but could be done. Also, I wonder if the kernel log works on BSD (not
tested), in which case the experimental code would work there without
any bad side effects (better phrased: with side-effects yet to be seen,
as I said I did so far not invest any serious time in testing).

Rainer

> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of Michael Biebl
> Sent: Wednesday, November 19, 2008 2:08 PM
> To: rsyslog-users
> Subject: Re: [rsyslog] rsyslogd security questions/comments
>
> 2008/11/19 Michael Biebl <mbiebl@gmail.com>:
> > 2008/11/19 Michael Biebl <mbiebl@gmail.com>:
> >
> >>
> >> /dev/klog could be made accessible via an ACL or a separate group.
> > ^^^^^^^^^^^^
> > Argh, /proc/kmsg, I mean.
>
> Looks like one can't set an ACL on a procfs unfortunately.
>
> Michael
>
>
> --
> Why is it that all of the instruments seeking intelligent life in the
> universe are pointed away from Earth?
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

For my usage, I need two modes of operation for syslog daemons.

1 - local syslog. Requires privileges to on local devices (/dev/log,
/dev/klogd or similar), write to local log-files, and send to
remote log server.

2 - central log server. Only listen on the needed network ports
(514/udp/tcp), and write to local log files (possibly also send
to other remote log servers).

For #1 I think it's OK not being able to chroot, keep more privileges,
etc., as the attacks against it will mostly be from local processes.

#2 needs to be *very* openly available on the network ports, since all
my servers needs to send logs to it. #2 will also be holding a lot more
sensitive data than #1, so I think this server needs to be protected as
much as possible. If chroot'ing, or dropping privileges prevents it from
reading from local /proc og /dev, I think that wouldn't matter much. One
could always run two instances on these few central servers, i.e. #1
sending to #2.


-jf

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

So it looks like the new idea, though not perfect, seems to provide some
value, at least under some circumstances. It also looks trivially to
implement. Most effort is probably to tell people precisely why it is
not a fully security guard. I'll see if I get this fully implemented
next week if nobody objects. I guess it's not more than a day's worth.

Rainer

> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of Jan-Frode Myklebust
> Sent: Friday, November 21, 2008 1:11 PM
> To: rsyslog@lists.adiscon.com
> Subject: Re: [rsyslog] rsyslogd security questions/comments
>
> For my usage, I need two modes of operation for syslog daemons.
>
> 1 - local syslog. Requires privileges to on local devices
> (/dev/log,
> /dev/klogd or similar), write to local log-files, and send to
> remote log server.
>
> 2 - central log server. Only listen on the needed network ports
> (514/udp/tcp), and write to local log files (possibly also
send
> to other remote log servers).
>
> For #1 I think it's OK not being able to chroot, keep more privileges,
> etc., as the attacks against it will mostly be from local processes.
>
> #2 needs to be *very* openly available on the network ports, since all
> my servers needs to send logs to it. #2 will also be holding a lot
more
> sensitive data than #1, so I think this server needs to be protected
as
> much as possible. If chroot'ing, or dropping privileges prevents it
> from
> reading from local /proc og /dev, I think that wouldn't matter much.
> One
> could always run two instances on these few central servers, i.e. #1
> sending to #2.
>
>
> -jf
>
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On Fri, 21 Nov 2008, Jan-Frode Myklebust wrote:

> For my usage, I need two modes of operation for syslog daemons.
>
> 1 - local syslog. Requires privileges to on local devices (/dev/log,
> /dev/klogd or similar), write to local log-files, and send to
> remote log server.
>
> 2 - central log server. Only listen on the needed network ports
> (514/udp/tcp), and write to local log files (possibly also send
> to other remote log servers).
>
> For #1 I think it's OK not being able to chroot, keep more privileges,
> etc., as the attacks against it will mostly be from local processes.
>
> #2 needs to be *very* openly available on the network ports, since all
> my servers needs to send logs to it. #2 will also be holding a lot more
> sensitive data than #1, so I think this server needs to be protected as
> much as possible.

just pointing out that on this central server the data will be in the same
place as the daemon listening to the network, and accessable to that
daemon, so chrooting, dropping privilages, etc won't protect the data that
gets logged (it will allow you to protect other data that lives on the
server, just not log data)

well, you could do something where rsyslog writes the file in the chroot,
and when it rolls the file something outside the chroot picks it up and
moves it elsewhere, but that's starting to get a little extreme.

> If chroot'ing, or dropping privileges prevents it from
> reading from local /proc og /dev, I think that wouldn't matter much. One
> could always run two instances on these few central servers, i.e. #1
> sending to #2.

correct.

David Lang
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On Fri, 21 Nov 2008, Rainer Gerhards wrote:

> So it looks like the new idea, though not perfect, seems to provide some
> value, at least under some circumstances. It also looks trivially to
> implement. Most effort is probably to tell people precisely why it is
> not a fully security guard. I'll see if I get this fully implemented
> next week if nobody objects. I guess it's not more than a day's worth.

I agree that even the limited version has benifits.

David Lang

> Rainer
>
>> -----Original Message-----
>> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
>> bounces@lists.adiscon.com] On Behalf Of Jan-Frode Myklebust
>> Sent: Friday, November 21, 2008 1:11 PM
>> To: rsyslog@lists.adiscon.com
>> Subject: Re: [rsyslog] rsyslogd security questions/comments
>>
>> For my usage, I need two modes of operation for syslog daemons.
>>
>> 1 - local syslog. Requires privileges to on local devices
>> (/dev/log,
>> /dev/klogd or similar), write to local log-files, and send to
>> remote log server.
>>
>> 2 - central log server. Only listen on the needed network ports
>> (514/udp/tcp), and write to local log files (possibly also
> send
>> to other remote log servers).
>>
>> For #1 I think it's OK not being able to chroot, keep more privileges,
>> etc., as the attacks against it will mostly be from local processes.
>>
>> #2 needs to be *very* openly available on the network ports, since all
>> my servers needs to send logs to it. #2 will also be holding a lot
> more
>> sensitive data than #1, so I think this server needs to be protected
> as
>> much as possible. If chroot'ing, or dropping privileges prevents it
>> from
>> reading from local /proc og /dev, I think that wouldn't matter much.
>> One
>> could always run two instances on these few central servers, i.e. #1
>> sending to #2.
>>
>>
>> -jf
>>
>> _______________________________________________
>> rsyslog mailing list
>> http://lists.adiscon.net/mailman/listinfo/rsyslog
>> http://www.rsyslog.com
> _______________________________________________
> rsyslog mailing list
> http://lists.adiscon.net/mailman/listinfo/rsyslog
> http://www.rsyslog.com
>
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On Fri, Nov 21, 2008 at 07:31, <david@lang.hm> wrote:
> just pointing out that on this central server the data will be in the same
> place as the daemon listening to the network, and accessable to that
> daemon, so chrooting, dropping privilages, etc won't protect the data that
> gets logged (it will allow you to protect other data that lives on the
> server, just not log data)

As is the same with all chrooted processes - the chroot model prevents
untrusted processes from messing with each other's candy, not their
own. If anyone that runs a chroot thinks otherwise, they're sorely
mistaken. It's why web servers are often chrooted with no write
access: the only writing they can do is back through specific ports
(database, syslog, memcache, etc.)

> well, you could do something where rsyslog writes the file in the chroot,
> and when it rolls the file something outside the chroot picks it up and
> moves it elsewhere, but that's starting to get a little extreme.

I absolutely agree that approach is foolish - better to give the
process no write permissions at all and have it either log to a
database (INSERT-only user) or run a two-layered approach wherein the
chrooted log server passes the [scrubbed] logs it receives back over a
pipe or to a secondary syslog service. Crash/subvert the front layer,
you have little place to go.

RB
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On 2008-11-21, RB <aoz.syn@gmail.com> wrote:
> On Fri, Nov 21, 2008 at 07:31, <david@lang.hm> wrote:
>> just pointing out that on this central server the data will be in the same
>> place as the daemon listening to the network, and accessable to that
>> daemon, so chrooting, dropping privilages, etc won't protect the data that
>> gets logged (it will allow you to protect other data that lives on the
>> server, just not log data)
>
> As is the same with all chrooted processes - the chroot model prevents
> untrusted processes from messing with each other's candy, not their
> own. If anyone that runs a chroot thinks otherwise, they're sorely
> mistaken.

I think the chroot() limits the possibility of:

- executing anything outside the chroot (f.ex. /bin/sh)
- write a new file, and execute it (noexec on the chroot mountpoint)
- overwrite something outside the chroot. I'm an itsy bit worried that
something like this:

$template PerAppLogs,"/var/log/apps/%programname%.log"
*.* -?PerAppLogs

could be tricked to write to unexpected places if you mess with
%programname%, or other similar variables that the sender has complete
controle over.

so I would argue that my sensitive syslogged data is more secure in a
chroot environment where there are no other executables, than on a non-
chroot environment.



-jf

--
To know recursion, you must first know recursion.

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

Just a quick note:

> -----Original Message-----
> From: rsyslog-bounces@lists.adiscon.com [mailto:rsyslog-
> bounces@lists.adiscon.com] On Behalf Of Jan-Frode Myklebust
> Sent: Friday, November 21, 2008 6:35 PM
> To: rsyslog@lists.adiscon.com
> Subject: Re: [rsyslog] rsyslogd security questions/comments
> I'm an itsy bit worried
> that
> something like this:
>
> $template PerAppLogs,"/var/log/apps/%programname%.log"
> *.* -?PerAppLogs
>
> could be tricked to write to unexpected places if you mess with
> %programname%, or other similar variables that the sender has
> complete
> controle over.

Definitely. Though not a complete cure, the secpath-* property replacer
options prevent at least slashes inside programname. I know this is not
100% bullet proof, but it should be applied. Otherwise, you don't need a
malicious user, a simple program error is sufficient to screw up things.

So the template is suggested to be

$template
PerAppLogs,"/var/log/apps/%programname:::secpath-replace%.log"

>From the doc:
---
secpath-replace Replace slashes inside the field by an
underscore. (e.g. "a/b" becomes "a_b"). Useful for secure pathname
generation (with dynafiles).
---

Full source at http://www.rsyslog.com/doc-property_replacer.html

I just thought I mention it.

Rainer
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On 2008-11-21, Rainer Gerhards <rgerhards@hq.adiscon.com> wrote:
>
> Definitely. Though not a complete cure, the secpath-* property replacer
> options prevent at least slashes inside programname. I know this is not
> 100% bullet proof, but it should be applied. Otherwise, you don't need a
> malicious user, a simple program error is sufficient to screw up things.


Oh, I didn't know about this one. Thanks!


-jf

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On Fri, Nov 21, 2008 at 10:34, Jan-Frode Myklebust <janfrode@tanso.net> wrote:
> I think the chroot() limits the possibility of:
>
> - executing anything outside the chroot (f.ex. /bin/sh)
> - write a new file, and execute it (noexec on the chroot mountpoint)
> - overwrite something outside the chroot. I'm an itsy bit worried that
> something like this:

You are absolutely correct - an unbroken chroot() provides a security
boundary that prevents the process[es] therein from accessing
filesystem resources outside that boundary. Permissions on the
directory structure at & below that point can provide additional
restrictions (like noexec).

> so I would argue that my sensitive syslogged data is more secure in a
> chroot environment where there are no other executables, than on a non-
> chroot environment.

Argue what you like, but your basis is flawed. You seem to forget
that most exploits bring their own executable [shell]code with them
and often operate purely in-memory. Therefore they don't strictly
need external executables; the lack thereof is more of a nuisance than
a roadblock.

System designers _must_ assume that any successful remote attacker may
access anything the application can, with the same permissions and
executing arbitrary code - chroot or not. If the data you are logging
is sufficiently sensitive that no client should be able to read the
data and any possibility of their doing so would be catastrophic, you
are going to have to either establish a one-way transport out of that
syslog chroot() or limit your scope to the point that remote attackers
are no longer a possibility.


RB
_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com

On 2008-11-21, RB <aoz.syn@gmail.com> wrote:
>
>> so I would argue that my sensitive syslogged data is more secure in a
>> chroot environment where there are no other executables, than on a non-
>> chroot environment.
>
> Argue what you like, but your basis is flawed. You seem to forget
> that most exploits bring their own executable [shell]code with them
> and often operate purely in-memory. Therefore they don't strictly
> need external executables; the lack thereof is more of a nuisance than
> a roadblock.

Did you see the comment from Rainer about the secpath-replace property?
I think that proves my basis is not flawed. The chroot here protects
against code flaws, or configuration flaws that could otherwise give
attacker the possibility of overwriting system files.

Also you pointing at "most exploits bring their own executable .. operate
purely in-memory" argument is flawed when I'm arguing for chroot being
*more* secure. Not 100% secure against all flaws, but *more* secure than
a non-chrooted process.

.. but dropping privileges is higher up on my wishlist, than chroot()..


-jf

--
http://xkcd.com/386/ ;-)

_______________________________________________
rsyslog mailing list
http://lists.adiscon.net/mailman/listinfo/rsyslog
http://www.rsyslog.com