Bug 250453 - nasd opens sockets from communications in /tmp
Summary: nasd opens sockets from communications in /tmp
Alias: None
Product: Fedora
Classification: Fedora
Component: nas
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Frank Büttner
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2007-08-01 18:06 UTC by Daniel Walsh
Modified: 2007-11-30 22:12 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2007-08-11 17:34:17 UTC

Attachments (Terms of Use)
Still some problems. This is the policy I will go with (479 bytes, application/octet-stream)
2007-08-20 21:02 UTC, Daniel Walsh
no flags Details
Interface file (1.55 KB, application/octet-stream)
2007-08-20 21:03 UTC, Daniel Walsh
no flags Details
TE File (3.02 KB, application/octet-stream)
2007-08-20 21:03 UTC, Daniel Walsh
no flags Details

Description Daniel Walsh 2007-08-01 18:06:40 UTC
Description of problem:

This is a bad idea.  It blows up stuff like polinstantiated /tmp directoryies. 
Also opens your system to potential security violations if multiple users can
share tmp, I could trick the program nasd server into doing something bad. 
Socket communications with userspace should be done through /var/run  The way
dbus does it.

Comment 1 Ken YANG 2007-08-02 06:26:50 UTC
nothing but add myself to cc list. 

btw, i agree what Daniel said

Comment 2 Frank Büttner 2007-08-02 17:23:19 UTC
I will look at the weekend for it.

Comment 3 Frank Büttner 2007-08-11 15:47:38 UTC
Do you mean /tmp/.sockets/audio10?

Comment 4 Frank Büttner 2007-08-11 17:34:17 UTC
So I build an patch and add it for the devel repo. Please verify it.

Comment 5 Ken YANG 2007-08-16 10:20:56 UTC
i have modified the selinux soundserver policy, based on frank's bugfix:


please review it

Comment 6 Frank Büttner 2007-08-16 17:09:11 UTC
it looks ok for my.

Comment 7 Daniel Walsh 2007-08-20 21:02:54 UTC
Created attachment 161919 [details]
Still some problems.  This is the policy I will go with

Comment 8 Daniel Walsh 2007-08-20 21:03:22 UTC
Created attachment 161920 [details]
Interface file

Comment 9 Daniel Walsh 2007-08-20 21:03:49 UTC
Created attachment 161921 [details]
TE File

Comment 10 Ken YANG 2007-08-21 03:02:25 UTC
hi wlash, 

i saw your modifications, and had four questions:

why use soundd_socket_t, instead of soundd_var_run_t, there are not 
soundd_socket_t used in soundserver policy module.

in soundserver_read_socket_files(), why change type requires, but in 
allow rules, still use soundd_var_run_t?

why add manage_files_pattern()? originally, audio$n is labeled in fc 
as socket file, and there are manage_socket_files_pattern()

why add "file sock_file" in files_pid_filetrans()? i think "dir" is 
enough, the socket audio$n created in /var/run/nasd will labeled with 
the containing directory.

Comment 11 Daniel Walsh 2007-08-21 17:18:40 UTC
1,2 your right, I guess I should have gone home earlied,  To much selinux policy
work :^(
Should be soundd_var_run_t

3.  What about the actual pid file?

4, Ok  removed.

Comment 12 Ken YANG 2007-08-22 02:40:44 UTC
i know the merge work of policy is huge, so many details you must 
carry with. i hope i can help you. 

yes, you are right. 

maybe i have not understand completely what pidfile mean.

i search policy source, i found most pidfile(call files_pid_file()) 
are *_var_run_t(socket file), or real pid file(e.g. auditd.pid). 

so i guess what the term "pidfile" mean is: pidfile are all files 
which only belong to current process.

is my guess right?

Comment 13 Daniel Walsh 2007-08-22 12:52:22 UTC
Yes, I think it is poorly named.  This function is for all files/dir/sockets
created in var_run.  Usually this is only the pid file.

Note You need to log in before you can comment on or make changes to this bug.