Allow userdomains to send syslog messages

PATCH New Sven Vermeulen 3 participants 13 messages Aug 23, 2011 – Aug 25, 2011

Share & tools

Sven Vermeulen

author

2011-08-23 10:57 UTC #0 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Some applications that run within the user domain send messages to the syslog daemon (for instance through the syslog() function). This patch allows the userdomain to write to the devlog_t socket and interact properly with the syslog daemon.

Signed-off-by Sven Vermeulen <[email protected]>

---
 policy/modules/system/userdomain.if |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

policy/modules/system/userdomain.if +2 -0

index c6d3cc8..17abfcf 100644
@@ -965,6 +965,8 @@ template(`userdom_unpriv_user_template', `
 	# cjp: why?
 	files_read_kernel_symbol_table($1_t)
 
+	logging_send_syslog_msg($1_t)
+
 	ifndef(`enable_mls',`
 		fs_exec_noxattr($1_t)

Signature · 1 line

1.7.3.4

Christopher J. PeBenito

2011-08-24 13:10 UTC #1 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 4 lines · Sven Vermeulen

Some applications that run within the user domain send messages to the syslog daemon (for instance through the syslog() function). This patch allows the userdomain to write to the devlog_t socket and interact properly with the syslog daemon.

Do you have some examples? My initial reaction is definitely not merged, as I don't want users to be able to flood the system logs.

Quoted 18 lines

Signed-off-by Sven Vermeulen <[email protected]>

---
 policy/modules/system/userdomain.if |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

policy/modules/system/userdomain.if +2 -0

index c6d3cc8..17abfcf 100644
@@ -965,6 +965,8 @@ template(`userdom_unpriv_user_template', `
 	# cjp: why?
 	files_read_kernel_symbol_table($1_t)
 
+	logging_send_syslog_msg($1_t)
+
 	ifndef(`enable_mls',`
 		fs_exec_noxattr($1_t)

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Dominick Grift

2011-08-24 13:15 UTC #2 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 8 lines · Christopher J. PeBenito

Quoted 4 lines · Sven Vermeulen
Some applications that run within the user domain send messages to the syslog daemon (for instance through the syslog() function). This patch allows the userdomain to write to the devlog_t socket and interact properly with the syslog daemon.
Do you have some examples? My initial reaction is definitely not merged, as I don't want users to be able to flood the system logs.

I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?

Quoted 15 lines

Signed-off-by Sven Vermeulen <[email protected]>

---
 policy/modules/system/userdomain.if |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

policy/modules/system/userdomain.if +0 -0

index c6d3cc8..17abfcf 100644
@@ -965,6 +965,8 @@ template(`userdom_unpriv_user_template', `
 	# cjp: why?
 	files_read_kernel_symbol_table($1_t)

Quoted 15 lines

Quoted 5 lines

policy/modules/system/userdomain.if +2 -0

+	logging_send_syslog_msg($1_t)
+
 	ifndef(`enable_mls',`
 		fs_exec_noxattr($1_t)

Signature · 7 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com
_______________________________________________
refpolicy mailing list
refpolicy at oss.tresys.com
http://oss.tresys.com/mailman/listinfo/refpolicy

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
Url : http://oss.tresys.com/pipermail/refpolicy/attachments/20110824/b2a56548/attachment.bin

Christopher J. PeBenito

2011-08-24 13:41 UTC #3 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 11 lines · Dominick Grift

Quoted 8 lines · Christopher J. PeBenito
Quoted 4 lines · Sven Vermeulen
Some applications that run within the user domain send messages to the syslog daemon (for instance through the syslog() function). This patch allows the userdomain to write to the devlog_t socket and interact properly with the syslog daemon.
Do you have some examples? My initial reaction is definitely not merged, as I don't want users to be able to flood the system logs.
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?

Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Dominick Grift

2011-08-24 13:51 UTC #4 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 3 lines · Christopher J. PeBenito

Quoted 2 lines · Dominick Grift
Quoted 1 line · Christopher J. PeBenito
On 08/23/11 06:57, Sven Vermeulen wrote:

... snip ...

Quoted 4 lines

Quoted 1 line
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.

Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.

Quoted 4 lines

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Christopher J. PeBenito

2011-08-24 14:16 UTC #5 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 11 lines · Dominick Grift

Quoted 3 lines · Christopher J. PeBenito
Quoted 2 lines · Dominick Grift
Quoted 1 line · Christopher J. PeBenito
On 08/23/11 06:57, Sven Vermeulen wrote:
... snip ...
Quoted 4 lines
Quoted 1 line
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.
Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.

Ok. I don't see this as a good reason to allow this. A user running a daemon should be logging to their home directory.

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Dominick Grift

2011-08-24 14:31 UTC #6 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 8 lines · Christopher J. PeBenito

Quoted 7 lines · Dominick Grift
Quoted 3 lines · Christopher J. PeBenito
Quoted 2 lines · Dominick Grift
Quoted 1 line · Christopher J. PeBenito
On 08/23/11 06:57, Sven Vermeulen wrote:
... snip ...
Quoted 2 lines
Quoted 1 line
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?

Quoted 7 lines

Quoted 4 lines
Quoted 2 lines
Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.
Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
Ok. I don't see this as a good reason to allow this. A user running a daemon should be logging to their home directory.

Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.

It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.

So in light of that it may be sensible to allow administrators to tune the policy to allow Git session daemon to syslog.

Quoted 5 lines

Signature · 4 lines

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Christopher J. PeBenito

2011-08-24 16:11 UTC #7 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 12 lines · Dominick Grift

Quoted 11 lines · Christopher J. PeBenito
Quoted 10 lines · Dominick Grift
Quoted 3 lines · Christopher J. PeBenito
Quoted 2 lines · Dominick Grift
Quoted 1 line · Christopher J. PeBenito
On 08/23/11 06:57, Sven Vermeulen wrote:
... snip ...
Quoted 4 lines
Quoted 1 line
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.

Quoted 8 lines

Quoted 4 lines
Quoted 1 line
Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
Ok. I don't see this as a good reason to allow this. A user running a daemon should be logging to their home directory.
Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.

If a user can run it as a user service w/o inetd, then why can't it run as a system service w/o inetd? Why cant you use start-stop-daemon or su to run it with a different uid?

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Dominick Grift

2011-08-24 16:23 UTC #8 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 18 lines · Christopher J. PeBenito

Quoted 17 lines · Dominick Grift
Quoted 15 lines · Christopher J. PeBenito
Quoted 11 lines · Dominick Grift
Quoted 3 lines · Christopher J. PeBenito
Quoted 2 lines · Dominick Grift
Quoted 1 line · Christopher J. PeBenito
On 08/23/11 06:57, Sven Vermeulen wrote:
... snip ...
Quoted 4 lines
Quoted 1 line
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.
Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
Ok. I don't see this as a good reason to allow this. A user running a daemon should be logging to their home directory.

Quoted 6 lines

Quoted 3 lines
Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.
If a user can run it as a user service w/o inetd, then why can't it run as a system service w/o inetd?

It could but that is not supported by default (there is no sysv init script) atleast not in Fedora.

Quoted 1 line

Why cant you use start-stop-daemon or su to run it with a different uid?

I guess yoo could, but what is your point? By default on (x)?inetd system service is supported. Sure you can hack around that and make it an init daemon but should we support that? If you hack it to run it as a sysv init daemon then i guess you could use su in the init script (that doesnt exist) and run git-daemon as a system service and as an unpriv user at the same time.

The point is that it is meant to run as an xinetd service domain.

Actually you could specify in /etc/xinetd.d/git that you want to run it as an different user but you will still needs xinetd running. Administrator just might to want to run inetd just for Git.

I rather support a something that makes sense (admin being allowed to tune policy to allow git user daemons to log to syslog in case desired), than support some hypothetical scenario where some admin decides to hack some sysv init script to get Git daemon to run as an init daemon instead of the supported xinetd service domain.

Quoted 5 lines

--
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Christopher J. PeBenito

2011-08-25 11:09 UTC #9 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 30 lines · Dominick Grift

Quoted 18 lines · Christopher J. PeBenito
Quoted 17 lines · Dominick Grift
Quoted 15 lines · Christopher J. PeBenito
Quoted 11 lines · Dominick Grift
Quoted 3 lines · Christopher J. PeBenito
Quoted 2 lines · Dominick Grift
Quoted 1 line · Christopher J. PeBenito
On 08/23/11 06:57, Sven Vermeulen wrote:
... snip ...
Quoted 4 lines
Quoted 1 line
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.
Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
Ok. I don't see this as a good reason to allow this. A user running a daemon should be logging to their home directory.
Quoted 6 lines
Quoted 3 lines
Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.
If a user can run it as a user service w/o inetd, then why can't it run as a system service w/o inetd?
It could but that is not supported by default (there is no sysv init script) atleast not in Fedora.
Quoted 1 line
Why cant you use start-stop-daemon or su to run it with a different uid?

Quoted 7 lines

I guess yoo could, but what is your point? By default on (x)?inetd system service is supported. Sure you can hack around that and make it an init daemon but should we support that? If you hack it to run it as a sysv init daemon then i guess you could use su in the init script (that doesnt exist) and run git-daemon as a system service and as an unpriv user at the same time.
The point is that it is meant to run as an xinetd service domain.
Actually you could specify in /etc/xinetd.d/git that you want to run it as an different user but you will still needs xinetd running. Administrator just might to want to run inetd just for Git.
I rather support a something that makes sense (admin being allowed to tune policy to allow git user daemons to log to syslog in case desired), than support some hypothetical scenario where some admin decides to hack some sysv init script to get Git daemon to run as an init daemon instead of the supported xinetd service domain.

Frankly, I think that users running git daemons is just as contrived, if not more.

Signature · 3 lines

Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Dominick Grift

2011-08-25 11:21 UTC #10 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

Quoted 33 lines · Christopher J. PeBenito

Quoted 32 lines · Dominick Grift
Quoted 18 lines · Christopher J. PeBenito
Quoted 17 lines · Dominick Grift
Quoted 15 lines · Christopher J. PeBenito
Quoted 11 lines · Dominick Grift
Quoted 3 lines · Christopher J. PeBenito
Quoted 2 lines · Dominick Grift
Quoted 1 line · Christopher J. PeBenito
On 08/23/11 06:57, Sven Vermeulen wrote:
... snip ...
Quoted 4 lines
Quoted 1 line
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.
Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
Ok. I don't see this as a good reason to allow this. A user running a daemon should be logging to their home directory.
Quoted 6 lines
Quoted 3 lines
Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.
If a user can run it as a user service w/o inetd, then why can't it run as a system service w/o inetd?
It could but that is not supported by default (there is no sysv init script) atleast not in Fedora.
Quoted 1 line
Why cant you use start-stop-daemon or su to run it with a different uid?
I guess yoo could, but what is your point? By default on (x)?inetd system service is supported. Sure you can hack around that and make it an init daemon but should we support that? If you hack it to run it as a sysv init daemon then i guess you could use su in the init script (that doesnt exist) and run git-daemon as a system service and as an unpriv user at the same time.

Quoted 8 lines

Quoted 5 lines
The point is that it is meant to run as an xinetd service domain.
Actually you could specify in /etc/xinetd.d/git that you want to run it as an different user but you will still needs xinetd running. Administrator just might to want to run inetd just for Git.
I rather support a something that makes sense (admin being allowed to tune policy to allow git user daemons to log to syslog in case desired), than support some hypothetical scenario where some admin decides to hack some sysv init script to get Git daemon to run as an init daemon instead of the supported xinetd service domain.
Frankly, I think that users running git daemons is just as contrived, if not more.

I suspected that this convo was moving this way.

Is it our job to tell people what they can and cannot do? I do not believe so.
I believe it is our job to facilitate integrity in the case of Type Enforcement; not to cripple the system by ignoring functionality.

That said, i do agree with your point in general, i just think we should leave that decision to the administrator and support both assumptions.

In the case of Git sessions using syslog, i would say make it tunable and disable by default.

If you do not want unprivileged users to run git sessions at all, i can imagine that to. So we could remove the session role templates calls but still leave the template in the interface file, so that i could be called if desired.

Or we could make unprivileged user domain transitions to the git session domain tunable as well.

But ignoring functionality altogether does not make SELinux a credible access control layer that can be supported by default (think Redhat, the distro that has the gut and sense of leadership to enable SELinux by default) in my opinion.

Quoted 5 lines

Signature · 4 lines

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Dominick Grift

2011-08-25 09:56 UTC #11 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

In reply to Christopher J. PeBenito

Quoted 18 lines · Christopher J. PeBenito

Quoted 17 lines · Dominick Grift
Quoted 15 lines · Christopher J. PeBenito
Quoted 11 lines · Dominick Grift
Quoted 3 lines · Christopher J. PeBenito
Quoted 2 lines · Dominick Grift
Quoted 1 line · Christopher J. PeBenito
On 08/23/11 06:57, Sven Vermeulen wrote:
... snip ...
Quoted 4 lines
Quoted 1 line
I do, the git-daemon run by users can be configured to use syslog. I allowed this by default in my git policy. Would you prefer a boolean "git_session_daemon_can_syslog" instead of allowing it by default?
Thats a different domain. I'm speaking of unpriv user domains user_t, staff_t, etc.
Until a git (session) daemon domain is implemented it runs in the unprivileged user domain.
Ok. I don't see this as a good reason to allow this. A user running a daemon should be logging to their home directory.

Quoted 7 lines

Quoted 3 lines
Agreed, but what if the administrator decides to run it as an unprivileged user and still wants to it to syslog.
It seems actually very sane to me. Running git-daemon as a system service requires inetd and it runs as root. Running inetd just to export a repository might be a bit much. If you can achieve what you want by running it as a unpriv user then why not.
If a user can run it as a user service w/o inetd, then why can't it run as a system service w/o inetd? Why cant you use start-stop-daemon or su to run it with a different uid?

Anyhow, if the git session daemon policy is generally accepted. i will be more than happy to send an additional patch removing the privilege for git_session_t to use syslog. Better something than nothing at all...

Quoted 5 lines

Signature · 4 lines

-- 
Chris PeBenito
Tresys Technology, LLC
www.tresys.com | oss.tresys.com

Sven Vermeulen

author

2011-08-24 19:50 UTC #12 lore raw

PATCH 1/1 Allow userdomains to send syslog messages

In reply to Christopher J. PeBenito

Quoted 9 lines · Christopher J. PeBenito

Quoted 4 lines · Sven Vermeulen
Some applications that run within the user domain send messages to the syslog daemon (for instance through the syslog() function). This patch allows the userdomain to write to the devlog_t socket and interact properly with the syslog daemon.
Do you have some examples? My initial reaction is definitely not merged, as I don't want users to be able to flood the system logs.

The one that triggered the creation of the patch was to support bashlogger (feature of bash that logs all activity to the system logger). Another one we had a way back (but I just informed the user how to allow it for himself then) was for a chat client (i think it was weechatter, but the case was applicable to others as well) configured to log things to the system log.

I don't mind if this is deemed a bit too intrusive for regular purposes.

Wkr,
Sven Vermeulen