From eric at brouhaha.com Thu Mar 2 01:38:56 2006 From: eric at brouhaha.com (Eric Smith) Date: Wed, 1 Mar 2006 17:38:56 -0800 (PST) Subject: Postfix/mailman problem Message-ID: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> I've got an FC4 x86_64 system with the targeted policy. I'm only just beginning to understand SELinux, after reading the O'Reilly book. I'm trying to use the Postfix MTA with GNU Mailman, using the postfix-to-mailman-2.1.py script. I put the script in /usr/lib/mailman/bin, but it fails. /var/log/maillog says: Mar 1 17:26:34 donnybrook pipe[10056]: fatal: pipe_comand: execvp /usr/lib/mailman/bin/postfix-to-mailman-2.1.py: Permission denied Mar 1 17:26:35 donnybrook postfix/pipe[10055]: 4D0F150087: to=, relay=mailman, delay=1, status=bounced (Command died with status 1: "/usr/lib/mailman/bin/postfix-to-mailman-2.1.py") /var/log/audit/audit.log says: type=AVC msg=audit(1141262794.346:48506): avc: denied { execute } for pid=10056 comm="pipe" name="postfix-to-mailman-2.1.py" dev=dm-6 ino=786433 scontext=system_u:system_r:postfix_pipe_t tcontext=system_u:object_r:mailman_queue_exec_t tclass=file As root, I tried: % chcon -u system_u -r system_r -t postfix_pipe_t postfix-to-mailman-2.1.py chcon: failed to change context of postfix-to-mailman-2.1.py to system_u:system_r:postfix_pipe_t: Permission denied Why can't I do that, or what should I do instead to make this work? Thanks! Eric From eric at brouhaha.com Thu Mar 2 04:45:05 2006 From: eric at brouhaha.com (Eric Smith) Date: Wed, 1 Mar 2006 20:45:05 -0800 (PST) Subject: Postfix/mailman problem In-Reply-To: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> Message-ID: <1214.67.111.12.176.1141274705.squirrel@67.111.12.176> I wrote about trying to get Postfix working with Mailman: > As root, I tried: > % chcon -u system_u -r system_r -t postfix_pipe_t > postfix-to-mailman-2.1.py > chcon: failed to change context of postfix-to-mailman-2.1.py to > system_u:system_r:postfix_pipe_t: Permission denied > > Why can't I do that, or what should I do instead to make this work? I found that if I turned off enforcing the chcon would succeed. However, when I turn enforcing back on, Postfix is still unable to invoke the postfix-to-mailman script. With enforcing off, it works fine, so I'm really curious as to what I need to do to make it work properly with enforcing on. Thanks, Eric From ivg2 at cornell.edu Thu Mar 2 19:02:10 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 02 Mar 2006 14:02:10 -0500 Subject: Postfix/mailman problem In-Reply-To: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> Message-ID: <44074132.7020702@cornell.edu> > type=AVC msg=audit(1141262794.346:48506): avc: denied { execute } for > pid=10056 comm="pipe" name="postfix-to-mailman-2.1.py" dev=dm-6 ino=786433 > scontext=system_u:system_r:postfix_pipe_t > tcontext=system_u:object_r:mailman_queue_exec_t tclass=file > > As root, I tried: > % chcon -u system_u -r system_r -t postfix_pipe_t postfix-to-mailman-2.1.py > chcon: failed to change context of postfix-to-mailman-2.1.py to > system_u:system_r:postfix_pipe_t: Permission denied > > Why can't I do that, or what should I do instead to make this work? This is definitely wrong - postfix_pipe_t is a process domain type - you shouldn't mark files of this type. I haven't worked on the postfix pipe policy, but it seems like the only thing it can execute at the moment is procmail. I would say: - the type mailman_queue_exec_t looks wrong for that file - how did it get this type? - the file /usr/lib/mailman/mail (which your script runs) appears to be a SGID executable to group mailman which runs other [mailman] programs. It has type lib_t, which is incorrect. I think whatever regexps are currently used in policy are overly generic, and misclassify lots of things as lib_t. (1) the regexp should be made more specific, and either (2) the file should be properly labeled with its own expression match, or (3) the program should be made to use /bin and /sbin like everyone else. - ultimately this boils down to postfix_pipe being unable to execute mailman. This is actually a more general problem - how do you confine a program, which allows the user to legitimately configure running arbitrary things in multiple other domains (i.e. pipe)? The same problem exists for example in gnome-session. Do you try to enumerate what domains can and can't be ran in policy? Doesn't that limit the usefullness of the program? On the other hand we certainly don't want important daemons to run whatever they want to - the point of selinux is confinement, so a program which is taken over can't get out of control. In the short run, maybe a macro can be added to postfix that takes a domain and allows postfix_pipe to run that. Same for gnome session, if that's ever confined. The opposite approach (enumeration in the executing program) seems wrong, since it doesn't allow 3rd party integration. From ivg2 at cornell.edu Thu Mar 2 19:19:07 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 02 Mar 2006 14:19:07 -0500 Subject: AVC when configuring printer..... In-Reply-To: <4c4ba1530602270809v52ea81e8k7ce5b0dc4bbbb10b@mail.gmail.com> References: <4c4ba1530602270809v52ea81e8k7ce5b0dc4bbbb10b@mail.gmail.com> Message-ID: <4407452B.30303@cornell.edu> > type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc: denied { read > } for pid=5773 comm=printconf-backe name=.fonts.cache-2 dev=dm-0 > ino=555510 scontext=system_u:system_r:cupsd_config_t:s0 > tcontext=system_u:object_r:user_home_t:s0 tclass=file > Does it work? This is likely harmless. However, we should be making use of the fact that this file (.fonts.cache-2) is now in its own directory. I specifically filed a bug to get it moved, and now we should write policy to take advantage of that, by: - prelabeling this folder with the correct type in our profile script, or any future solution, so that the cache can be created with the correct type by libfontconfig - allowing programs that need to read fonts to read that type (moving font-related macros from the old strict policy into the new refpol). It's unfortunate all those problems were solved in the old strict policy, and now they all have to be re-solved for refpol. > type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc: denied { > write } for pid=5773 comm=printconf-backe name=[21844] dev=pipefs > ino=21844 scontext=system_u:system_r:cupsd_config_t:s0 > tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_file > This isn't very helpful - what is it trying to write to - grep for 21844. (Does lsof show that number?) From ivg2 at cornell.edu Thu Mar 2 19:32:27 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 02 Mar 2006 14:32:27 -0500 Subject: FC4 + samba + selinux In-Reply-To: <1140967819.464.4.camel@localhost.localdomain> References: <1140926671.16142.9.camel@soncomputer> <1140967819.464.4.camel@localhost.localdomain> Message-ID: <4407484B.4070303@cornell.edu> Eric Paris wrote: > What is / labeled? In order for smbd to even get to /data/samba it has > to be able to search on / and /data. Check out 'ls -Zd /' and 'ls - > Zd /data' and make sure they are of types smbd can search. My first > guess is that / is labeled wrong (I think it sholud be > system_u:object_r:root_t) > I think we should allow smbd to search all directories if this is the case. Alternatively we can have system-config-samba generate policy for this on the fly, and alert the user, but that will be a pain, and seems unnecessary. From eric at brouhaha.com Thu Mar 2 20:06:24 2006 From: eric at brouhaha.com (Eric Smith) Date: Thu, 2 Mar 2006 12:06:24 -0800 (PST) Subject: Postfix/mailman problem In-Reply-To: <44074132.7020702@cornell.edu> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> Message-ID: <1258.67.111.12.103.1141329984.squirrel@67.111.12.103> > I haven't worked on the postfix pipe policy, but it seems like the only > thing it can execute at the moment is procmail. How is that determined? I can't find a single reference to procmail anywhere in the SELinux targeted configuration, and procmail doesn't seem to have any special context: # ls --lcontext /usr/bin/procmail -rwxr-xr-x 1 system_u:object_r:bin_t root mail 100680 Mar 18 2005 /usr/bin/procmail > I would say: > - the type mailman_queue_exec_t looks wrong for that file - how did it > get this type? I'm not sure, actually. Should it just be system_u:object_r:bin_t? > - the file /usr/lib/mailman/mail (which your script runs) appears to be > a SGID executable to group mailman which runs other [mailman] programs. > It has type lib_t, which is incorrect. I think whatever regexps are > currently used in policy are overly generic, and misclassify lots of > things as lib_t. Should I change its context to system_u:object_r:bin_t? > In the short run, maybe a macro can be added to postfix that takes a > domain and allows postfix_pipe to run that. Makes sense. I don't have any idea how to do it, though perhaps I can find time this weekend to study the O'Reilly book more. Thanks! Eric From eric at brouhaha.com Thu Mar 2 20:08:59 2006 From: eric at brouhaha.com (Eric Smith) Date: Thu, 2 Mar 2006 12:08:59 -0800 (PST) Subject: Postfix/mailman problem In-Reply-To: <44074132.7020702@cornell.edu> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> Message-ID: <1263.67.111.12.103.1141330139.squirrel@67.111.12.103> Ivan wrote: > - the type mailman_queue_exec_t looks wrong for that file - how did it > get this type? And I said that I don't know. Actually, the entire /usr/lib/mailman directory somehow got its contexts screwed up, and I ran restorecon. Maybe it set that context on the postfix-to-mailman script, on the basis of the execute permission being set? Otherwise I still have no clue. Eric From ivg2 at cornell.edu Thu Mar 2 20:34:10 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 02 Mar 2006 15:34:10 -0500 Subject: Postfix/mailman problem In-Reply-To: <1258.67.111.12.103.1141329984.squirrel@67.111.12.103> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> <1258.67.111.12.103.1141329984.squirrel@67.111.12.103> Message-ID: <440756C2.9040605@cornell.edu> > How is that determined? I can't find a single reference to procmail > anywhere in the SELinux targeted configuration, and procmail doesn't > seem to have any special context: > > # ls --lcontext /usr/bin/procmail > -rwxr-xr-x 1 system_u:object_r:bin_t root mail 100680 Mar 18 > 2005 /usr/bin/procmail > I run strict policy, you probably don't have a procmail policy installed. I determined this by running looking at the policy.conf in the generated policy.conf file from a refpolicy cvs build. I also looked at the policy source. allow postfix_pipe_t postfix_pipe_exec_t:file { read getattr lock execute ioctl }; allow postfix_pipe_t postfix_pipe_exec_t:file { { read getattr lock execute ioctl } execute_no_trans }; allow postfix_pipe_t postfix_exec_t:file { read getattr lock execute ioctl }; allow postfix_pipe_t shell_exec_t:file { { read getattr lock execute ioctl } execute_no_trans }; allow postfix_pipe_t ld_so_t:file { read getattr lock execute ioctl }; allow postfix_pipe_t { shlib_t textrel_shlib_t }:file { read getattr lock execute ioctl }; allow postfix_pipe_t procmail_exec_t:file { getattr read execute }; type_transition postfix_pipe_t var_run_t:file postfix_var_run_t; type_transition postfix_master_t postfix_pipe_exec_t:process postfix_pipe_t; type_transition postfix_pipe_t procmail_exec_t:process procmail_t; >> I would say: >> - the type mailman_queue_exec_t looks wrong for that file - how did it >> get this type? >> > > I'm not sure, actually. Should it just be system_u:object_r:bin_t? > Did you install this file yourself? bin_t certainly seems more correct... But it doesn't really matter what it is - pipe still won't be able to transition into the mailman domain until policy is written for that. >> - the file /usr/lib/mailman/mail (which your script runs) appears to be >> a SGID executable to group mailman which runs other [mailman] programs. >> It has type lib_t, which is incorrect. I think whatever regexps are >> currently used in policy are overly generic, and misclassify lots of >> things as lib_t. >> > > Should I change its context to system_u:object_r:bin_t? > Anything you change that is not a customizable type can later get un-done by restorecon. This should be fixed in policy. From ivg2 at cornell.edu Thu Mar 2 20:56:11 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Thu, 02 Mar 2006 15:56:11 -0500 Subject: Postfix/mailman problem In-Reply-To: <1263.67.111.12.103.1141330139.squirrel@67.111.12.103> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> <1263.67.111.12.103.1141330139.squirrel@67.111.12.103> Message-ID: <44075BEB.5060004@cornell.edu> > And I said that I don't know. Actually, the entire /usr/lib/mailman > directory somehow got its contexts screwed up, and I ran restorecon. > Maybe it set that context on the postfix-to-mailman script, I don't see that script in the current mailman package. > on the > basis of the execute permission being set? Contexts should be set in the following way [ to the best of my knowledge...could be wrong ] ============================================== - if the creating program calls setfscreatecon() in libselinux, the next created file has that type - if a rule exists in policy which maps the pair (src_con, target_class) -> target_con, then the object of type target_class created by a process in src_con gets its context changed to target_con. This is an automatic transition. - otherwise, the context is set to match the context of the parent directory From selinux at gmail.com Thu Mar 2 21:00:49 2006 From: selinux at gmail.com (Tom London) Date: Thu, 2 Mar 2006 13:00:49 -0800 Subject: AVC when configuring printer..... In-Reply-To: <4407452B.30303@cornell.edu> References: <4c4ba1530602270809v52ea81e8k7ce5b0dc4bbbb10b@mail.gmail.com> <4407452B.30303@cornell.edu> Message-ID: <4c4ba1530603021300y5294caf4p249af9e70fb52edf@mail.gmail.com> On 3/2/06, Ivan Gyurdiev wrote: > > > type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc: denied { read > > } for pid=5773 comm=printconf-backe name=.fonts.cache-2 dev=dm-0 > > ino=555510 scontext=system_u:system_r:cupsd_config_t:s0 > > tcontext=system_u:object_r:user_home_t:s0 tclass=file > > > Does it work? This is likely harmless. > However, we should be making use of the fact that this file > (.fonts.cache-2) is now in its own directory. I specifically filed a bug > to get it moved, and now we should write policy to take advantage of > that, by: > > - prelabeling this folder with the correct type in our profile script, > or any future solution, so that the cache can be created with the > correct type by libfontconfig > > - allowing programs that need to read fonts to read that type > (moving font-related macros from the old strict policy into the new > refpol). > > It's unfortunate all those problems were solved in the old strict > policy, and now they all have to be re-solved for refpol. > > > type=AVC msg=audit(02/27/2006 08:04:15.126:101) : avc: denied { > > write } for pid=5773 comm=printconf-backe name=[21844] dev=pipefs > > ino=21844 scontext=system_u:system_r:cupsd_config_t:s0 > > tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_file > > > This isn't very helpful - what is it trying to write to - grep for 21844. > (Does lsof show that number?) > > Sorry for the lack of specifics here, but it was all I could get at the time. Didn't think about 'grep XX | lsof'. Recreating yields: type=AVC msg=audit(1141332960.725:64): avc: denied { write } for pid=8214 comm="printconf-backe" name="[48007]" dev=pipefs ino=48007 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_filetype=AVC msg=audit(1141332960.725:64): avc: denied { write } for pid=8214 comm="printconf-backe" name="[48008]" dev=pipefs ino=48008 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_filetype=AVC msg=audit(1141332960.725:64): avc: denied { write } for pid=8214 comm="printconf-backe" name="[48009]" dev=pipefs ino=48009 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:system_r:unconfined_t:s0 tclass=fifo_filetype=AVC msg=audit(1141332960.725:64): avc: denied { read } for pid=8214 comm="printconf-backe" name=".fonts.cache-2" dev=dm-0 ino=555510 scontext=system_u:system_r:cupsd_config_t:s0 tcontext=system_u:object_r:user_home_t:s0 tclass=file type=SYSCALL msg=audit(1141332960.725:64): arch=40000003 syscall=11 success=yes exit=0 a0=9029dc8 a1=9029e18 a2=9029f20 a3=9026d70 items=3 pid=8214 auid=500 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="printconf-backe" exe="/usr/bin/python" type=AVC_PATH msg=audit(1141332960.725:64): path="/root/.rh-fontconfig/.fonts.cache-2" type=AVC_PATH msg=audit(1141332960.725:64): path="pipe:[48009]" type=AVC_PATH msg=audit(1141332960.725:64): path="pipe:[48008]" type=AVC_PATH msg=audit(1141332960.725:64): path="pipe:[48007]" type=CWD msg=audit(1141332960.725:64): cwd="/" type=PATH msg=audit(1141332960.725:64): item=0 name="/usr/sbin/printconf-backend" flags=101 inode=5790576 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1141332960.725:64): item=1 flags=101 inode=5786615 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 type=PATH msg=audit(1141332960.725:64): item=2 flags=101 inode=1045697 dev=fd:00 mode=0100755 ouid=0 ogid=0 rdev=00:00 'lsof | grep 4800' yields: [root at localhost ~]# lsof | grep 4800 Xorg 2494 root 35u unix 0xf6e48004 48012 /tmp/.X11-unix/X0 gnome-scr 2770 tbl 14u unix 0xf0b48004 23919 socket firefox-b 2822 tbl 34u REG 253,0 2048000 6928883 /home/tbl/.mozilla/firefox/bdyi67iu.default/Cache/_CACHE_003_ printconf 8186 root 6r FIFO 0,5 48007 pipe printconf 8186 root 7w FIFO 0,5 48007 pipe printconf 8186 root 8r FIFO 0,5 48008 pipe printconf 8186 root 9w FIFO 0,5 48008 pipe printconf 8186 root 10r FIFO 0,5 48009 pipe printconf 8186 root 11w FIFO 0,5 48009 pipe [root at localhost ~]# So these are all printconf pipes. What other info can I provide? Trivial test of just 'applying' the existing config appears not to break anything. So, this could be harmless.... tom -- Tom London From eric at brouhaha.com Thu Mar 2 22:39:32 2006 From: eric at brouhaha.com (Eric Smith) Date: Thu, 2 Mar 2006 14:39:32 -0800 (PST) Subject: Postfix/mailman problem In-Reply-To: <44074132.7020702@cornell.edu> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> Message-ID: <2117.67.111.12.103.1141339172.squirrel@67.111.12.103> Ivan wrote: > - the file /usr/lib/mailman/mail (which your script runs) appears to be > a SGID executable to group mailman which runs other [mailman] programs. [...] > ultimately this boils down to postfix_pipe being unable to execute > mailman. However, it isn't even able to invoke the python script. To make that work, does the policy need to allow postfix_pipe_t to run python? The python script isn't that complicated; I could rewrite it in C if necessary. I tried my hand at adding mailman rules to postfix.te: ifdef(`mailman.te', ` domain_auto_trans(postfix_pipe_t, mailman_exec_t, mailman_t) ') but that doesn't appear to work, possibly because mailman.te defines mailman_$1_t, and I don't have any idea what $1 is. Thanks, Eric [and thanks for putting up with my SELinux newbie questions!] From ivg2 at cornell.edu Fri Mar 3 10:00:19 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 03 Mar 2006 05:00:19 -0500 Subject: FC4 + samba + selinux In-Reply-To: <1141334224.2790.1.camel@soncomputer> References: <1140926671.16142.9.camel@soncomputer> <1140967819.464.4.camel@localhost.localdomain> <4407484B.4070303@cornell.edu> <1141334224.2790.1.camel@soncomputer> Message-ID: <440813B3.9050604@cornell.edu> > >> I think we should allow smbd to search all directories if this is the >> case. Alternatively we can have system-config-samba generate policy for >> this on the fly, and alert the user, but that will be a pain, and seems >> unnecessary. >> >> > Maybe have system-config-samba make sure the directory is properly > labeled with mnt_t or samba_share_t? I think Eric's point was that smbd needs directory search access on the entire path to the directory. I haven't verified that this is correct, but from past experience I suspect it's true. Labeling everything on the path as samba_share_t or mnt_t is usually not possible. From ivg2 at cornell.edu Fri Mar 3 10:06:16 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 03 Mar 2006 05:06:16 -0500 Subject: Postfix/mailman problem In-Reply-To: <2117.67.111.12.103.1141339172.squirrel@67.111.12.103> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> <2117.67.111.12.103.1141339172.squirrel@67.111.12.103> Message-ID: <44081518.1010409@cornell.edu> > However, it isn't even able to invoke the python script. To make that > work, does the policy need to allow postfix_pipe_t to run python? > Yes. It seems like it's currently able to run shells (shell_exec_t). Doesn't appear like it can run python (bin_t). > The python script isn't that complicated; I could rewrite it in C if > necessary. > This shouldn't be necessary. > I tried my hand at adding mailman rules to postfix.te: > > ifdef(`mailman.te', ` > domain_auto_trans(postfix_pipe_t, mailman_exec_t, mailman_t) > ') > > but that doesn't appear to work, When you say something doesn't work, that could mean anything - to find out what is going on, you need to look at the audit log, and see exactly what is denied. Then you can try to write policy to fix it. Also, I think enumerating what can be run in the postfix policy is not a very good idea - should have a macro instead, to be called by client domains. The macro would go into postfix.if. > possibly because mailman.te defines > mailman_$1_t, and I don't have any idea what $1 is. > That's probably defined inside an m4 macro of some sort. $1 expands to the first argument of that macro - it's a variable. Usually it stands for a "prefix", which most of the time simply means a selinux role (user, staff, or sysadm) To find out for sure you have to grep for that macro, and see what argument it's called with. The XML spec in the .if file should explain what each argument stands for. From ivg2 at cornell.edu Fri Mar 3 10:29:10 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Fri, 03 Mar 2006 05:29:10 -0500 Subject: AVC when configuring printer..... In-Reply-To: <4c4ba1530603021300y5294caf4p249af9e70fb52edf@mail.gmail.com> References: <4c4ba1530602270809v52ea81e8k7ce5b0dc4bbbb10b@mail.gmail.com> <4407452B.30303@cornell.edu> <4c4ba1530603021300y5294caf4p249af9e70fb52edf@mail.gmail.com> Message-ID: <44081A76.2060308@cornell.edu> > So these are all printconf pipes. Printconf runs in unconfined_t, and printconf-backend runs in cupsd_config_t (not sure if they should be setup like that, I suspect this might have been done to restrict what can acccess the cupsd domains). It seems they need to communicate via pipes. Looking at the current policy, rules are already in place [ for targeted ] to allow reading unconfined pipes from cupsd_config_t, but no rules exist for writing data back to unconfined pipes (communication in the other direction). Either printconf should be moved into cupsd_config_t too.... or cupsd_config_t should be allowed to write as well as read from unconfined pipes. > Trivial test of just 'applying' the existing config appears not to > break anything. So, this could be harmless.... > That usually means we haven't found out what the problem is yet, and it's non-fatal (which doesn't necessarily mean harmless). From selinux at gmail.com Fri Mar 3 15:03:24 2006 From: selinux at gmail.com (Tom London) Date: Fri, 3 Mar 2006 07:03:24 -0800 Subject: AVC when configuring printer..... In-Reply-To: <44081A76.2060308@cornell.edu> References: <4c4ba1530602270809v52ea81e8k7ce5b0dc4bbbb10b@mail.gmail.com> <4407452B.30303@cornell.edu> <4c4ba1530603021300y5294caf4p249af9e70fb52edf@mail.gmail.com> <44081A76.2060308@cornell.edu> Message-ID: <4c4ba1530603030703r416cfa1dn210de30c8b7a0584@mail.gmail.com> On 3/3/06, Ivan Gyurdiev wrote: > > > So these are all printconf pipes. > Printconf runs in unconfined_t, and printconf-backend runs in > cupsd_config_t (not sure if they should be setup like that, I suspect > this might have been done to restrict what can acccess the cupsd > domains). It seems they need to communicate via pipes. Looking at the > current policy, rules are already in place [ for targeted ] to allow > reading unconfined pipes from cupsd_config_t, but no rules exist for > writing data back to unconfined pipes (communication in the other > direction). > > Either printconf should be moved into cupsd_config_t too.... or > cupsd_config_t should be allowed to write as well as read from > unconfined pipes. > > > Trivial test of just 'applying' the existing config appears not to > > break anything. So, this could be harmless.... > > > That usually means we haven't found out what the problem is yet, and > it's non-fatal (which doesn't necessarily mean harmless). > Ivan, I agree: non-fatal is not the same as harmless. Thanks for taking the time to analyze this. tom -- Tom London From selinux at gmail.com Fri Mar 3 15:59:49 2006 From: selinux at gmail.com (Tom London) Date: Fri, 3 Mar 2006 07:59:49 -0800 Subject: hald AVCs from today's rawhide Message-ID: <4c4ba1530603030759n5f6a89b2h52ca7dd1db20d221@mail.gmail.com> Running today's rawhide, targeted/enforcing. Noticed the following. ---- type=PATH msg=audit(03/03/2006 07:07:50.170:13) : item=0 name=/proc/sys/vm/ flags=follow,access inode=4026531930 dev=00:03 mode=dir,555 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(03/03/2006 07:07:50.170:13) : cwd=/usr/share/hal/scripts type=SYSCALL msg=audit(03/03/2006 07:07:50.170:13) : arch=i386 syscall=access success=no exit=-13(Permission denied) a0=8566400 a1=2 a2=2 a3=8565878 items=1 pid=2489 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=pm-powersave exe=/bin/bash type=AVC msg=audit(03/03/2006 07:07:50.170:13) : avc: denied { write } for pid=2489 comm=pm-powersave name=vm dev=proc ino=-268435366 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=dir ---- type=PATH msg=audit(03/03/2006 07:07:51.358:14) : item=0 name=/proc/sys/vm/ flags=follow,access inode=4026531930 dev=00:03 mode=dir,555 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(03/03/2006 07:07:51.358:14) : cwd=/usr/share/hal/scripts type=SYSCALL msg=audit(03/03/2006 07:07:51.358:14) : arch=i386 syscall=access success=no exit=-13(Permission denied) a0=9d16400 a1=2 a2=2 a3=9d15878 items=1 pid=2520 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=pm-powersave exe=/bin/bash type=AVC msg=audit(03/03/2006 07:07:51.358:14) : avc: denied { write } for pid=2520 comm=pm-powersave name=vm dev=proc ino=-268435366 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=dir ---- tom -- Tom London From eric at brouhaha.com Fri Mar 3 17:38:43 2006 From: eric at brouhaha.com (Eric Smith) Date: Fri, 3 Mar 2006 09:38:43 -0800 (PST) Subject: Postfix/mailman problem In-Reply-To: <44081518.1010409@cornell.edu> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> <2117.67.111.12.103.1141339172.squirrel@67.111.12.103> <44081518.1010409@cornell.edu> Message-ID: <51703.71.129.198.222.1141407523.squirrel@71.129.198.222> Ivan wrote: > Yes. It seems like it's currently able to run shells (shell_exec_t). > Doesn't appear like it can run python (bin_t). Hmmm... maybe Python should be considered a shell? From the POV of SELinux policy, is the defining characteristic of a shell that it is interactive, or that it runs scripts? I notice that the bash has shell_exec_t, which csh has only bin_t. > Also, I think enumerating what can be run in the postfix policy is not a > very good idea - should have a macro instead, to be called by client > domains. The macro would go into postfix.if. Sure, but my immediate goal is to find the simplest way to change it such that I can turn enforcing back on again on my server. While it would be great to do it in a correct and elegant manner, I think it's going to be a while before I understand this stuff well enough to do that. Eric From kcarr at tresys.com Fri Mar 3 20:06:21 2006 From: kcarr at tresys.com (Kevin Carr) Date: Fri, 3 Mar 2006 15:06:21 -0500 Subject: ANN: CDS Framework IDE In-Reply-To: <20060301155858.GB28021@sergelap.austin.ibm.com> Message-ID: <200603032006.k23K6LNq015906@gotham.columbia.tresys.com> > I was very happy to see these announcements :) > > However, when I try to create a new project with either of these > plugins, I get the following errors: > > com.tresys.slide.plugin.wizards.NewProjectWizard > com.tresys.framework.plugin.wizards.NewProjectWizard > > Never used eclipse before... dunno if this is user error. It looks like these errors are because of an older version of eclipse. Both tools require Eclipse 3.1. On another note, I updated the Tresys Technology website to include some installation instructions for the CDS Framework IDE. Also I posted a newer tarball for the CDS tool that fixes some issues we found yesterday. Please get the newer release and try that one. http://tresys.com/selinux Kevin Carr Tresys Technology 410.290.1411 x137 From selinux at gmail.com Sat Mar 4 23:05:25 2006 From: selinux at gmail.com (Tom London) Date: Sat, 4 Mar 2006 15:05:25 -0800 Subject: AVCs during suspend/resume (vbetool/hald/ntpd) Message-ID: <4c4ba1530603041505o26bee1f0m2f7b6242ac9b593e@mail.gmail.com> Running latest rawhide (2.6.15-1.2009.4.2_FC), targeted/enforcing, some AVCs are generated (I think during resume). Running in Permissive mode, I get: ---- type=PATH msg=audit(03/04/2006 14:39:51.707:29) : item=1 flags=follow,open inode=1045516 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=PATH msg=audit(03/04/2006 14:39:51.707:29) : item=0 name=/usr/sbin/vbetool flags=follow,open inode=5794873 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(03/04/2006 14:39:51.707:29) : cwd=/usr/share/hal/scripts type=AVC_PATH msg=audit(03/04/2006 14:39:51.707:29) : path=/var/run/vbestate type=SYSCALL msg=audit(03/04/2006 14:39:51.707:29) : arch=i386 syscall=execve success=yes exit=0 a0=8a49e98 a1=8a49eb0 a2=8a4f980 a3=8a4f528 items=2 pid=2933 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=vbetool exe=/usr/sbin/vbetool type=AVC msg=audit(03/04/2006 14:39:51.707:29) : avc: denied { write } for pid=2933 comm=vbetool name=vbestate dev=dm-0 ino=2777558 scontext=system_u:system_r:vbetool_t:s0 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file ---- type=PATH msg=audit(03/04/2006 14:40:31.194:30) : item=1 flags=follow,open inode=1045516 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=PATH msg=audit(03/04/2006 14:40:31.194:30) : item=0 name=/usr/sbin/vbetool flags=follow,open inode=5794873 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(03/04/2006 14:40:31.194:30) : cwd=/usr/share/hal/scripts type=AVC_PATH msg=audit(03/04/2006 14:40:31.194:30) : path=/var/run/vbestate type=SYSCALL msg=audit(03/04/2006 14:40:31.194:30) : arch=i386 syscall=execve success=yes exit=0 a0=9268650 a1=927d070 a2=9268980 a3=9268518 items=2 pid=3115 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=vbetool exe=/usr/sbin/vbetool type=AVC msg=audit(03/04/2006 14:40:31.194:30) : avc: denied { read } for pid=3115 comm=vbetool name=vbestate dev=dm-0 ino=2777558 scontext=system_u:system_r:vbetool_t:s0 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file ---- type=AVC_PATH msg=audit(03/04/2006 14:40:31.222:31) : path=/var/run/vbestate type=SYSCALL msg=audit(03/04/2006 14:40:31.222:31) : arch=i386 syscall=ioctl success=no exit=-25(Inappropriate ioctl for device) a0=0 a1=4b3a a2=0 a3=bfc59044 items=0 pid=3115 auid=unknown(1515870810) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=vbetool exe=/usr/sbin/vbetool type=AVC msg=audit(03/04/2006 14:40:31.222:31) : avc: denied { ioctl } for pid=3115 comm=vbetool name=vbestate dev=dm-0 ino=2777558 scontext=system_u:system_r:vbetool_t:s0 tcontext=system_u:object_r:hald_var_run_t:s0 tclass=file ---- type=PATH msg=audit(03/04/2006 14:40:33.010:32) : item=0 name=/dev/tty8 flags=follow inode=681 dev=00:0f mode=char,660 ouid=root ogid=tty rdev=04:08 type=CWD msg=audit(03/04/2006 14:40:33.010:32) : cwd=/usr/share/hal/scripts type=SYSCALL msg=audit(03/04/2006 14:40:33.010:32) : arch=i386 syscall=chown32 success=yes exit=0 a0=bf97d207 a1=0 a2=0 a3=bf97d2c4 items=1 pid=3126 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=openvt exe=/usr/bin/openvt type=AVC msg=audit(03/04/2006 14:40:33.010:32) : avc: denied { setattr } for pid=3126 comm=openvt name=tty8 dev=tmpfs ino=681 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:tty_device_t:s0 tclass=chr_file ---- type=PATH msg=audit(03/04/2006 14:40:51.308:33) : item=1 flags=follow,open inode=1045516 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=PATH msg=audit(03/04/2006 14:40:51.308:33) : item=0 name=/usr/sbin/ntpdate flags=follow,open inode=5802324 dev=fd:00 mode=file,755 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(03/04/2006 14:40:51.308:33) : cwd=/ type=AVC_PATH msg=audit(03/04/2006 14:40:51.308:33) : path=/dev/null type=SYSCALL msg=audit(03/04/2006 14:40:51.308:33) : arch=i386 syscall=execve success=yes exit=0 a0=9aa9458 a1=9aaa320 a2=9aab1b0 a3=9aaa838 items=2 pid=3182 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=ntpdate exe=/usr/sbin/ntpdate type=AVC msg=audit(03/04/2006 14:40:51.308:33) : avc: denied { use } for pid=3182 comm=ntpdate name=null dev=tmpfs ino=1151 scontext=system_u:system_r:ntpd_t:s0 tcontext=system_u:system_r:hald_t:s0 tclass=fd ---- <<<<<>>>>>>> ---- type=PATH msg=audit(03/04/2006 14:46:19.552:13) : item=0 name=/proc/sys/vm/ flags=follow,access inode=4026531930 dev=00:03 mode=dir,555 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(03/04/2006 14:46:19.552:13) : cwd=/usr/share/hal/scripts type=SYSCALL msg=audit(03/04/2006 14:46:19.552:13) : arch=i386 syscall=access success=no exit=-13(Permission denied) a0=9c3a3c8 a1=2 a2=2 a3=9c39538 items=1 pid=2695 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=pm-powersave exe=/bin/bash type=AVC msg=audit(03/04/2006 14:46:19.552:13) : avc: denied { write } for pid=2695 comm=pm-powersave name=vm dev=proc ino=-268435366 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=dir ---- type=PATH msg=audit(03/04/2006 14:46:22.004:14) : item=0 name=/proc/sys/vm/ flags=follow,access inode=4026531930 dev=00:03 mode=dir,555 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(03/04/2006 14:46:22.004:14) : cwd=/usr/share/hal/scripts type=SYSCALL msg=audit(03/04/2006 14:46:22.004:14) : arch=i386 syscall=access success=no exit=-13(Permission denied) a0=8e403c8 a1=2 a2=2 a3=8e3f538 items=1 pid=2733 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=pm-powersave exe=/bin/bash type=AVC msg=audit(03/04/2006 14:46:22.004:14) : avc: denied { write } for pid=2733 comm=pm-powersave name=vm dev=proc ino=-268435366 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=dir ---- -- Tom London From suman.nari at gmail.com Sun Mar 5 07:52:24 2006 From: suman.nari at gmail.com (Suman B) Date: Sun, 5 Mar 2006 13:22:24 +0530 Subject: can any one help me on SELinux plzzzz Message-ID: <63889910603042352x32d36e9fu32bfdfcbf465aefd@mail.gmail.com> Hi, i am doing M.Tech and I am doing my mini-project on SeLinux. My guide told me to modify the SeLinux code a bit and recompile the kernel. I have read some articles and working procedure of SeLinux but i am unable to decide the modification which i could do. Plz help me out from this problem. Thanks in advance Regrads, Suman.B NIT Calicut. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ivg2 at cornell.edu Sun Mar 5 10:09:52 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Sun, 05 Mar 2006 05:09:52 -0500 Subject: can any one help me on SELinux plzzzz In-Reply-To: <63889910603042352x32d36e9fu32bfdfcbf465aefd@mail.gmail.com> References: <63889910603042352x32d36e9fu32bfdfcbf465aefd@mail.gmail.com> Message-ID: <440AB8F0.2030705@cornell.edu> > i am doing M.Tech and I am doing my mini-project on SeLinux. My guide > told me to modify the SeLinux code a bit and recompile the kernel. I > have read some articles and working procedure of SeLinux but i am > unable to decide the modification which i could do. Plz help me out > from this problem. I wouldn't be able to help you with the kernel code for SELinux, but my suggestions would be. 1. describe the problem [ otherwise no one can help you ] 2. plz stop writing plz, it's driving me crazy (especially with lots of z's following it) From tdiehl at rogueind.com Sun Mar 5 16:16:14 2006 From: tdiehl at rogueind.com (Tom Diehl) Date: Sun, 5 Mar 2006 11:16:14 -0500 (EST) Subject: selinux, httpd and sudo Message-ID: Hi all, I have an el4 machine that I am trying to get a shell script working from a php page with sudo. I can su to apache and execute the script using sudo but when I try to execute the script from the php page I get the following avc's: type=AVC msg=audit(1141573880.162:1935): avc: denied { setrlimit } for pid=29788 comm="sudo" scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=process type=SYSCALL msg=audit(1141573880.162:1935): arch=c000003e syscall=160 success=no exit=-13 a0=4 a1=7fbffff9a0 a2=0 a3=7fbffff701 items=0 pid=29788 auid=0 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="sudo" exe="/usr/bin/sudo" type=AVC msg=audit(1141573880.164:1936): avc: denied { read } for pid=29788 comm="sudo" name="shadow" dev=dm-0 ino=51991 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:shadow_t tclass=file type=SYSCALL msg=audit(1141573880.164:1936): arch=c000003e syscall=2 success=no exit=-13 a0=2a95e1302a a1=0 a2=1b6 a3=1 items=1 pid=29788 auid=0 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="sudo" exe="/usr/bin/sudo" type=CWD msg=audit(1141573880.164:1936): cwd="/var/www/adddomain" type=PATH msg=audit(1141573880.164:1936): name="/etc/shadow" flags=101 inode=51991 dev=fd:00 mode=0100400 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1141573880.165:1937): avc: denied { read } for pid=29788 comm="sudo" name="shadow" dev=dm-0 ino=51991 scontext=root:system_r:httpd_sys_script_t tcontext=system_u:object_r:shadow_t tclass=file type=SYSCALL msg=audit(1141573880.165:1937): arch=c000003e syscall=2 success=no exit=-13 a0=2a95e1302a a1=0 a2=1b6 a3=4 items=1 pid=29788 auid=0 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="sudo" exe="/usr/bin/sudo" type=CWD msg=audit(1141573880.165:1937): cwd="/var/www/adddomain" type=PATH msg=audit(1141573880.165:1937): name="/etc/shadow" flags=101 inode=51991 dev=fd:00 mode=0100400 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1141573880.165:1938): avc: denied { create } for pid=29788 comm="sudo" scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=netlink_route_socket type=SYSCALL msg=audit(1141573880.165:1938): arch=c000003e syscall=41 success=no exit=-13 a0=10 a1=3 a2=0 a3=7fbfffe901 items=0 pid=29788 auid=0 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="sudo" exe="/usr/bin/sudo" type=AVC msg=audit(1141573880.166:1939): avc: denied { setgid } for pid=29788 comm="sudo" capability=6 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability type=SYSCALL msg=audit(1141573880.166:1939): arch=c000003e syscall=119 success=yes exit=0 a0=ffffffff a1=30 a2=ffffffff a3=7fbffff701 items=0 pid=29788 auid=0 uid=48 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="sudo" exe="/usr/bin/sudo" type=AVC msg=audit(1141573880.167:1940): avc: denied { setuid } for pid=29788 comm="sudo" capability=7 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability type=SYSCALL msg=audit(1141573880.167:1940): arch=c000003e syscall=117 success=yes exit=0 a0=30 a1=30 a2=0 a3=7fbffff701 items=0 pid=29788 auid=0 uid=48 gid=48 euid=48 suid=0 fsuid=48 egid=48 sgid=48 fsgid=48 comm="sudo" exe="/usr/bin/sudo" type=AVC msg=audit(1141573880.167:1941): avc: denied { setgid } for pid=29788 comm="sudo" capability=6 scontext=root:system_r:httpd_sys_script_t tcontext=root:system_r:httpd_sys_script_t tclass=capability type=SYSCALL msg=audit(1141573880.167:1941): arch=c000003e syscall=119 success=no exit=-1 a0=ffffffff a1=0 a2=ffffffff a3=7fbffff701 items=0 pid=29788 auid=0 uid=0 gid=48 euid=0 suid=0 fsuid=0 egid=48 sgid=48 fsgid=48 comm="sudo" exe="/usr/bin/sudo" If I am reading these correctly, it appears that selinux is stopping sudo from executing the commands. Is there a way to get this to work without making the system insecure. The script is restricted to internal use but there are publicly accessible websites hosted on the machine. Regards, Tom From rmy at tigress.co.uk Mon Mar 6 11:59:39 2006 From: rmy at tigress.co.uk (Ron Yorston) Date: Mon, 6 Mar 2006 11:59:39 GMT Subject: SELinux and /proc Message-ID: <200603061159.k26BxdTf021463@tiffany.internal.tigress.co.uk> Testing FC5T3 the other week I wanted to find the arguments that gdm had used when it started Xnest, so I ran: ps ax | grep Xnest This didn't produce the expected response. On further investigation I found that several processes weren't being listed by 'ps ax' when run as an ordinary user but were when run as root. Running ps under strace showed that it was failing to open files in /proc. This was clearly an SELinux issue, as rebooting with enforcing=0 made the problem go away. I raised this in bugzilla: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=183387 but the report has been closed as NOTABUG with the response: This is intended behaviour and part of SELinux with MCS policy. I'd like this to be reconsidered. I don't think that the targeted policy should break such long-standing Unix conventions as the behaviour of 'ps ax'. It's perfectly obvious to a user when they're running an X server, so having ps or top pretend that they're not doesn't seem very helpful. Ron From selinux at gmail.com Tue Mar 7 18:24:46 2006 From: selinux at gmail.com (Tom London) Date: Tue, 7 Mar 2006 10:24:46 -0800 Subject: dontaudit for Message-ID: <4c4ba1530603071024q78fcaf3dr822ea5c60faf02e@mail.gmail.com> Running targeted/enforcing, latest rawhide. I get this: ---- type=PATH msg=audit(03/07/2006 09:11:05.866:13) : item=0 name=/proc/sys/vm/ flags=follow,access inode=4026531930 dev=00:03 mode=dir,555 ouid=root ogid=root rdev=00:00 type=CWD msg=audit(03/07/2006 09:11:05.866:13) : cwd=/usr/share/hal/scripts type=SYSCALL msg=audit(03/07/2006 09:11:05.866:13) : arch=i386 syscall=access success=no exit=-13(Permission denied) a0=95213b8 a1=2 a2=2 a3=9520528 items=1 pid=2674 auid=unknown(4294967295) uid=root gid=root euid=root suid=root fsuid=root egid=root sgid=root fsgid=root comm=pm-powersave exe=/bin/bash type=AVC msg=audit(03/07/2006 09:11:05.866:13) : avc: denied { write } for pid=2674 comm=pm-powersave name=vm dev=proc ino=-268435366 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:sysctl_vm_t:s0 tclass=dir ---- I think it comes from /usr/sbin/pm-powersave: if [ ! -w "/proc/sys/vm/" ] ; then # Use the raw kernel sysfs interface echo "You do not have write access to /proc/sys/vm/" exit 1 fi /proc/sys/vm appers to not want to be written: [tbl at localhost vm]$ ls -ldZ /proc/sys/vm dr-xr-xr-x root root system_u:object_r:sysctl_vm_t /proc/sys/vm [tbl at localhost vm]$ Should this be a 'dontaudit'? E.g.: dontaudit hald_t sysctl_vm_t:dir write; tom -- Tom London From dant at cdkkt.com Wed Mar 8 17:16:55 2006 From: dant at cdkkt.com (Daniel B. Thurman) Date: Wed, 8 Mar 2006 09:16:55 -0800 Subject: Unable to create swapfiles.... Message-ID: Hi Daniel J Walsh, I have read the previous posts regarding creating swapfiles and SELinux refuses to allow it. The steps to create a swapfile is: 1) dd if=/dev/zero of=/swapfile bs=1024 count= 1.5) New step: chcon -t swapfile_t /swapfile 2) mkswap /swapfile 3) swapon /swapfile 4) Add entry to fstab All of this is per Redhat's documention - which is old. But with the inclusion of SELinux, a new security context of swapfile_t was added, and supposedly added to mkswap as well - and I have have the latest YUM updates since I am testing with FC5-T3 and I have done (1.5) above but when doing (2) I get a "relabel" denial with the message: > mkswap /swapfile mkswap: unable to relabel /swapfile to swapfile_t: Permission denied /var/log/audit/audit.log shows: type=AVC msg=audit(1141837284.182:194): avc: denied { ioctl } for pid=3948 comm="mkswap" name="swapfile" dev=hda7 ino=107915 scontext=root:system_r:fsadm_t:s0-s0:c0.c255 tcontext=root:object_r:swapfile_t:s0 tclass=file type=SYSCALL msg=audit(1141837284.182:194): arch=40000003 syscall=54 success=no exit=-13 a0=3 a1=1260 a2=bf9c1ed0 a3=bf9c39fb items=0 pid=3948 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mkswap" exe="/sbin/mkswap" type=AVC_PATH msg=audit(1141837284.182:194): path="/swapfile" type=AVC msg=audit(1141837284.238:195): avc: denied { relabelfrom } for pid=3948 comm="mkswap" name="swapfile" dev=hda7 ino=107915 scontext=root:system_r:fsadm_t:s0-s0:c0.c255 tcontext=root:object_r:swapfile_t:s0 tclass=file type=SYSCALL msg=audit(1141837284.238:195): arch=40000003 syscall=228 success=no exit=-13 a0=3 a1=250f66f a2=804a434 a3=b items=0 pid=3948 auid=0 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="mkswap" exe="/sbin/mkswap" Please let me know what solution is needed! Kind regards, Dan From lengyel at gmail.com Wed Mar 8 17:44:27 2006 From: lengyel at gmail.com (Florian Lengyel) Date: Wed, 8 Mar 2006 12:44:27 -0500 Subject: Modifying local policy onn RHEL 4 Message-ID: Is this the appropriate list to ask about modifying local Selinux policies on Red Hate Enterprise Linux 4? If it is, can someone inform me what i need to download in order to modify the local Selinux policy? The source and tools to do this don't seem to be included in my installation (following the online Red Hat documentation); perhaps there are appropriate rpms to download in up2date--I don't know what they are, and they do not seem to be mentioned in the online documentation. If this is not the appropriate list, please let me know. Thanks, FL -------------- next part -------------- An HTML attachment was scrubbed... URL: From gajownik at fedora.pl Wed Mar 8 18:03:03 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 08 Mar 2006 19:03:03 +0100 Subject: How to allow vsftpd to listen on other ports? Message-ID: <440F1C57.60502@fedora.pl> Hi! I wanted vsftpd to listen on 750 or 777 port. SELinux does not like this type=AVC msg=audit(1141840161.184:107): avc: denied { name_bind } for pid=5352 comm="vsftpd" src=777 scontext=root:system_r:ftpd_t tcontext=system_u:object_r:reserved_port_t tclass=tcp_socket type=AVC msg=audit(1141840470.444:114): avc: denied { name_bind } for pid=5495 comm="vsftpd" src=750 scontext=root:system_r:ftpd_t tcontext=system_u:object_r:kerberos_port_t tclass=tcp_socket I've downloaded selinux-policy-targeted-sources rpm and wanted to add this line: portcon tcp 750 system_u:object_r:ftp_port_t The problem is that I don't know where should it be placed. It does not work in domains/misc/local.te -- `make load' fails ;-) OS: FC4 selinux-policy-targeted-sources: 1.27.1-2.22 Regards, Dawid -- ^_* From sds at tycho.nsa.gov Wed Mar 8 18:12:07 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Mar 2006 13:12:07 -0500 Subject: Modifying local policy onn RHEL 4 In-Reply-To: References: Message-ID: <1141841527.6157.158.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-08 at 12:44 -0500, Florian Lengyel wrote: > Is this the appropriate list to ask about modifying local Selinux > policies on Red Hate Enterprise Linux 4? If it is, can someone inform > me what i need to download in order to modify the local Selinux > policy? The source and tools to do this don't seem to be included in > my installation (following the online Red Hat documentation); perhaps > there are appropriate rpms to download in up2date--I don't know what > they are, and they do not seem to be mentioned in the online > documentation. > > If this is not the appropriate list, please let me know. Look for selinux-policy-targeted-sources. That contains the policy sources. Also look for checkpolicy. That is the policy "compiler". -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Mar 8 18:14:25 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Mar 2006 13:14:25 -0500 Subject: How to allow vsftpd to listen on other ports? In-Reply-To: <440F1C57.60502@fedora.pl> References: <440F1C57.60502@fedora.pl> Message-ID: <1141841665.6157.161.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-08 at 19:03 +0100, Dawid Gajownik wrote: > Hi! > > I wanted vsftpd to listen on 750 or 777 port. SELinux does not like this > > type=AVC msg=audit(1141840161.184:107): avc: denied { name_bind } for > pid=5352 comm="vsftpd" src=777 scontext=root:system_r:ftpd_t > tcontext=system_u:object_r:reserved_port_t tclass=tcp_socket > type=AVC msg=audit(1141840470.444:114): avc: denied { name_bind } for > pid=5495 comm="vsftpd" src=750 scontext=root:system_r:ftpd_t > tcontext=system_u:object_r:kerberos_port_t tclass=tcp_socket > > I've downloaded selinux-policy-targeted-sources rpm and wanted to add > this line: > > portcon tcp 750 system_u:object_r:ftp_port_t > > The problem is that I don't know where should it be placed. It does not > work in domains/misc/local.te -- `make load' fails ;-) > > OS: FC4 > selinux-policy-targeted-sources: 1.27.1-2.22 Needs to go in net_contexts, and put before the catchall cases for reserved_port_t. In FC5, you'll have much nicer options for such customization via semanage without needing policy sources at all. -- Stephen Smalley National Security Agency From gajownik at fedora.pl Wed Mar 8 19:41:12 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 08 Mar 2006 20:41:12 +0100 Subject: How to allow vsftpd to listen on other ports? In-Reply-To: <1141841665.6157.161.camel@moss-spartans.epoch.ncsc.mil> References: <440F1C57.60502@fedora.pl> <1141841665.6157.161.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <440F3358.9090201@fedora.pl> Dnia 03/08/2006 07:11 PM, U?ytkownik Stephen Smalley napisa?: > Needs to go in net_contexts, and put before the catchall cases for > reserved_port_t. Thanks, it works but I wanted to avoid modifying this file. Does that mean that I will need to edit it after every selinux-policy-targetes-sources update? (I can use ftp port > 1023 so this entry wouldn't need to be placed before reserved_port_t) > In FC5, you'll have much nicer options for such customization via > semanage without needing policy sources at all. Yes, it's more user friendly :D I've just tested it on my rawhide box. semanage man page sucks a bit (no examples), so it took me few minutes to construct this command: semanage port -a -t ftp_port_t -p tcp 7777 Actually, it was unnecessary on FC5 ;-) It seems that SELinux policy does not block vsftpd from binding to other ports (or my system is broken?). I'm using selinux-policy-targeted-2.2.23-6 it if makes any differance. I had to modify http_port_t to allow Apache to work on 81 port, though... -- ^_* From sds at tycho.nsa.gov Wed Mar 8 19:59:18 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 08 Mar 2006 14:59:18 -0500 Subject: How to allow vsftpd to listen on other ports? In-Reply-To: <440F3358.9090201@fedora.pl> References: <440F1C57.60502@fedora.pl> <1141841665.6157.161.camel@moss-spartans.epoch.ncsc.mil> <440F3358.9090201@fedora.pl> Message-ID: <1141847958.6157.201.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-08 at 20:41 +0100, Dawid Gajownik wrote: > Dnia 03/08/2006 07:11 PM, U?ytkownik Stephen Smalley napisa?: > > > Needs to go in net_contexts, and put before the catchall cases for > > reserved_port_t. > > Thanks, it works but I wanted to avoid modifying this file. Does that > mean that I will need to edit it after every > selinux-policy-targetes-sources update? (I can use ftp port > 1023 so > this entry wouldn't need to be placed before reserved_port_t) I think so. One of the motivations for semanage in FC5. refpolicy also makes an improvement in this area even in the source policy situation IIUC, by allowing you to scatter portcon and similar statements throughout the policy source files and have the build process extract them for final processing. > Yes, it's more user friendly :D I've just tested it on my rawhide box. > semanage man page sucks a bit (no examples), so it took me few minutes > to construct this command: > > semanage port -a -t ftp_port_t -p tcp 7777 > > Actually, it was unnecessary on FC5 ;-) It seems that SELinux policy > does not block vsftpd from binding to other ports (or my system is > broken?). I'm using selinux-policy-targeted-2.2.23-6 it if makes any > differance. Policy (both FC4 and FC5) appear to allow ftpd to bind to generic ports (port_t) outside of the reserved range plus the ftp data port and the ftp service port. Did you mean 777 or 7777? One would be mapped to reserved_port_t, the other to port_t. > I had to modify http_port_t to allow Apache to work on 81 port, though... -- Stephen Smalley National Security Agency From selinux at gmail.com Wed Mar 8 22:41:37 2006 From: selinux at gmail.com (Tom London) Date: Wed, 8 Mar 2006 14:41:37 -0800 Subject: enableaudit.pp ... Message-ID: <4c4ba1530603081441s5f27cb38p4b8ee3b4fd7759ef@mail.gmail.com> Running latest targeted policy. /usr/share/selinux/targeted/base.pp and enableaudit.pp appear to be identical. That right? If so, I must not understand on how to use. So, how do I load a policy with all the 'dontaudit' rules removed? tom [Sorry for the dumb question....] -- Tom London From lengyel at gmail.com Wed Mar 8 23:20:10 2006 From: lengyel at gmail.com (Florian Lengyel) Date: Wed, 8 Mar 2006 18:20:10 -0500 Subject: Modifying local policy onn RHEL 4 In-Reply-To: <1141841527.6157.158.camel@moss-spartans.epoch.ncsc.mil> References: <1141841527.6157.158.camel@moss-spartans.epoch.ncsc.mil> Message-ID: On 3/8/06, Stephen Smalley wrote: > > On Wed, 2006-03-08 at 12:44 -0500, Florian Lengyel wrote: > > Is this the appropriate list to ask about modifying local Selinux > > policies on Red Hat Enterprise Linux 4? If it is, can someone inform > > me what i need to download in order to modify the local Selinux > > policy? The source and tools to do this don't seem to be included in > > my installation (following the online Red Hat documentation); perhaps > > there are appropriate rpms to download in up2date--I don't know what > > they are, and they do not seem to be mentioned in the online > > documentation. > > > > If this is not the appropriate list, please let me know. Thank you for this; you have jogged my memory that I am missing precisely those sources In the /etc/selinux/targeted/policy subdirectory [root at cml policy]# pwd /etc/selinux/targeted/policy There is a file called policy.18 [root at cml policy]# ls -latrs total 348 332 -rw-r--r-- 1 root root 331417 Mar 8 2005 policy.18 8 drwxr-xr-x 4 root root 4096 Aug 25 2005 .. 8 drwxr-xr-x 2 root root 4096 Aug 25 2005 . [root at cml policy]# but there is no /etc/selinux/policy/sources subdirectory The checkpolicy command is present: [root at cml policy]# pwd /etc/selinux/targeted/policy [root at cml policy]# ls -latrs total 348 332 -rw-r--r-- 1 root root 331417 Mar 8 2005 policy.18 8 drwxr-xr-x 4 root root 4096 Aug 25 2005 .. 8 drwxr-xr-x 2 root root 4096 Aug 25 2005 . [root at cml policy]# So I am missing the source directory. I wonder if the missing components are downloadable in rpm form... Look for selinux-policy-targeted-sources. > That contains the policy sources. > Also look for checkpolicy. That is the policy "compiler". > > -- > Stephen Smalley > National Security Agency > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mennis309 at gmail.com Wed Mar 8 23:43:49 2006 From: mennis309 at gmail.com (Mark Ennis) Date: Thu, 9 Mar 2006 10:43:49 +1100 Subject: Modifying local policy onn RHEL 4 In-Reply-To: References: <1141841527.6157.158.camel@moss-spartans.epoch.ncsc.mil> Message-ID: I think you will find that Stephen was referring to the RPMs: selinux-policy-targeted-sources-1.17.30-2.110.noarch.rpm checkpolicy-1.17.5-1.i386.rpm - Mark. On 3/9/06, Florian Lengyel wrote: > > > > On 3/8/06, Stephen Smalley wrote: > > > On Wed, 2006-03-08 at 12:44 -0500, Florian Lengyel wrote: > > Is this the appropriate list to ask about modifying local Selinux > > policies on Red Hat Enterprise Linux 4? If it is, can someone inform > > > me what i need to download in order to modify the local Selinux > > policy? The source and tools to do this don't seem to be included in > > my installation (following the online Red Hat documentation); perhaps > > there are appropriate rpms to download in up2date--I don't know what > > they are, and they do not seem to be mentioned in the online > > documentation. > > > > If this is not the appropriate list, please let me know. > > Thank you for this; you have jogged my memory that I am missing > precisely those sources In the /etc/selinux/targeted/policy subdirectory > [root at cml policy]# pwd > /etc/selinux/targeted/policy > > There is a file called policy.18 > > [root at cml policy]# ls -latrs > total 348 > 332 -rw-r--r-- 1 root root 331417 Mar 8 2005 policy.18 > 8 drwxr-xr-x 4 root root 4096 Aug 25 2005 .. > 8 drwxr-xr-x 2 root root 4096 Aug 25 2005 . > [root at cml policy]# > > but there is no /etc/selinux/policy/sources subdirectory > > The checkpolicy command is present: > > [root at cml policy]# pwd > /etc/selinux/targeted/policy > [root at cml policy]# ls -latrs > total 348 > 332 -rw-r--r-- 1 root root 331417 Mar 8 2005 policy.18 > 8 drwxr-xr-x 4 root root 4096 Aug 25 2005 .. > 8 drwxr-xr-x 2 root root 4096 Aug 25 2005 . > [root at cml policy]# > > So I am missing the source directory. I wonder if the missing components are > downloadable in rpm form... > > > > Look for selinux-policy-targeted-sources. > > That contains the policy sources. > > Also look for checkpolicy. That is the policy "compiler". > > > > -- > > Stephen Smalley > > National Security Agency > > > > > > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > From lengyel at gmail.com Wed Mar 8 23:51:37 2006 From: lengyel at gmail.com (Florian Lengyel) Date: Wed, 8 Mar 2006 18:51:37 -0500 Subject: Modifying local policy onn RHEL 4 In-Reply-To: References: <1141841527.6157.158.camel@moss-spartans.epoch.ncsc.mil> Message-ID: My apologies and thank you for clarifying. On 3/8/06, Mark Ennis wrote: > > I think you will find that Stephen was referring to the RPMs: > > selinux-policy-targeted-sources-1.17.30-2.110.noarch.rpm > checkpolicy-1.17.5-1.i386.rpm > > - Mark. > > On 3/9/06, Florian Lengyel wrote: > > > > > > > > On 3/8/06, Stephen Smalley wrote: > > > > > On Wed, 2006-03-08 at 12:44 -0500, Florian Lengyel wrote: > > > Is this the appropriate list to ask about modifying local Selinux > > > policies on Red Hat Enterprise Linux 4? If it is, can someone inform > > > > > me what i need to download in order to modify the local Selinux > > > policy? The source and tools to do this don't seem to be included in > > > my installation (following the online Red Hat documentation); perhaps > > > there are appropriate rpms to download in up2date--I don't know what > > > they are, and they do not seem to be mentioned in the online > > > documentation. > > > > > > If this is not the appropriate list, please let me know. > > > > Thank you for this; you have jogged my memory that I am missing > > precisely those sources In the /etc/selinux/targeted/policy subdirectory > > [root at cml policy]# pwd > > /etc/selinux/targeted/policy > > > > There is a file called policy.18 > > > > > > but there is no /etc/selinux/policy/sources subdirectory > > > > The checkpolicy command is present: > > > > [root at cml policy]# pwd > > /etc/selinux/targeted/policy > > [root at cml policy]# ls -latrs > > total 348 > > 332 -rw-r--r-- 1 root root 331417 Mar 8 2005 policy.18 > > 8 drwxr-xr-x 4 root root 4096 Aug 25 2005 .. > > 8 drwxr-xr-x 2 root root 4096 Aug 25 2005 . > > [root at cml policy]# > > > > So I am missing the source directory. I wonder if the missing components > are > > downloadable in rpm form... > > > > > > > Look for selinux-policy-targeted-sources. > > > That contains the policy sources. > > > Also look for checkpolicy. That is the policy "compiler". > > > > > > -- > > > Stephen Smalley > > > National Security Agency > > > > > > > > > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dwalsh at redhat.com Thu Mar 9 14:31:39 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Mar 2006 09:31:39 -0500 Subject: enableaudit.pp ... In-Reply-To: <4c4ba1530603081441s5f27cb38p4b8ee3b4fd7759ef@mail.gmail.com> References: <4c4ba1530603081441s5f27cb38p4b8ee3b4fd7759ef@mail.gmail.com> Message-ID: <44103C4B.7070500@redhat.com> Tom London wrote: > Running latest targeted policy. > > /usr/share/selinux/targeted/base.pp and enableaudit.pp appear to be identical. > > That right? If so, I must not understand on how to use. > > So, how do I load a policy with all the 'dontaudit' rules removed? > > tom > [Sorry for the dumb question....] > Good question. I have no idea why they are the same. I just built locally and they are different. I will send another package to the build machine and make sure they are different. > -- > Tom London > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Thu Mar 9 19:14:57 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 09 Mar 2006 14:14:57 -0500 Subject: enableaudit.pp ... In-Reply-To: <44103C4B.7070500@redhat.com> References: <4c4ba1530603081441s5f27cb38p4b8ee3b4fd7759ef@mail.gmail.com> <44103C4B.7070500@redhat.com> Message-ID: <44107EB1.5070508@redhat.com> Daniel J Walsh wrote: > Tom London wrote: >> Running latest targeted policy. >> >> /usr/share/selinux/targeted/base.pp and enableaudit.pp appear to be >> identical. >> >> That right? If so, I must not understand on how to use. >> >> So, how do I load a policy with all the 'dontaudit' rules removed? >> >> tom >> [Sorry for the dumb question....] >> > Good question. I have no idea why they are the same. I just built > locally and they are different. I will send another package to the > build machine and make sure they are different. Ok, I have fixed it. Looks like some kind of timing issue is confusing the Makefile into thinking the application is not new. Forcing the rebuild using the -W flag fixes the problem in selinux-policy-2.2.23-14 Dan >> -- >> Tom London >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From gajownik at fedora.pl Thu Mar 9 22:44:13 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 09 Mar 2006 23:44:13 +0100 Subject: How to allow vsftpd to listen on other ports? In-Reply-To: <1141847958.6157.201.camel@moss-spartans.epoch.ncsc.mil> References: <440F1C57.60502@fedora.pl> <1141841665.6157.161.camel@moss-spartans.epoch.ncsc.mil> <440F3358.9090201@fedora.pl> <1141847958.6157.201.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4410AFBD.6020808@fedora.pl> Dnia 03/08/2006 08:56 PM, U?ytkownik Stephen Smalley napisa?: >> semanage man page sucks a bit (no examples), so it took me few minutes >> to construct this command: >> >> semanage port -a -t ftp_port_t -p tcp 7777 Heh, I've found today this link ? http://fedoraproject.org/wiki/SELinux/FAQ/ProposedAdditions#head-b8a7b039fa3a44f1d20c4e5035992af02426709d :-) > Policy (both FC4 and FC5) appear to allow ftpd to bind to generic ports > (port_t) outside of the reserved range plus the ftp data port and the > ftp service port. I did not know that. I thought that policy blocks binding to any port except ftp_port_t. (Yes, I did not read domains/program/ftpd.te :P ) Hmmm... would you be willing to explain me why ftpd is allowed to bind to port_t? If it's done on purpose, why 1-1023 ports are so important that they cannot be used without policy modification? > Did you mean 777 or 7777? I used port 777 on FC4 and 7777 one on FC5 - I did not know that it would make a difference. Thanks for your help! -- ^_* From sds at tycho.nsa.gov Fri Mar 10 14:35:52 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 10 Mar 2006 09:35:52 -0500 Subject: How to allow vsftpd to listen on other ports? In-Reply-To: <4410AFBD.6020808@fedora.pl> References: <440F1C57.60502@fedora.pl> <1141841665.6157.161.camel@moss-spartans.epoch.ncsc.mil> <440F3358.9090201@fedora.pl> <1141847958.6157.201.camel@moss-spartans.epoch.ncsc.mil> <4410AFBD.6020808@fedora.pl> Message-ID: <1142001352.25454.76.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-03-09 at 23:44 +0100, Dawid Gajownik wrote: > I did not know that. I thought that policy blocks binding to any port > except ftp_port_t. (Yes, I did not read domains/program/ftpd.te :P ) > > Hmmm... would you be willing to explain me why ftpd is allowed to bind > to port_t? If it's done on purpose, why 1-1023 ports are so important > that they cannot be used without policy modification? It has been a while since I've looked at the specifics of that policy, but I suspect that ftpd wants to bind to arbitrary unreserved ports for data connections. Whereas you'd like to keep the reserved port space clean so that e.g. ftpd doesn't masquerade as some other well-known service. OTOH, if we are now keeping all well-defined port types defined in the base policy regardless of the set of policy modules included (which wasn't originally the case), then we might not need to concern ourselves with the reserved_port_t fallback. cc'd some other folks who may have an opinion. -- Stephen Smalley National Security Agency From gajownik at fedora.pl Fri Mar 10 16:05:51 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Fri, 10 Mar 2006 17:05:51 +0100 Subject: How to allow vsftpd to listen on other ports? In-Reply-To: <1142001352.25454.76.camel@moss-spartans.epoch.ncsc.mil> References: <440F1C57.60502@fedora.pl> <1141841665.6157.161.camel@moss-spartans.epoch.ncsc.mil> <440F3358.9090201@fedora.pl> <1141847958.6157.201.camel@moss-spartans.epoch.ncsc.mil> <4410AFBD.6020808@fedora.pl> <1142001352.25454.76.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4411A3DF.6090805@fedora.pl> Dnia 03/10/2006 03:34 PM, U?ytkownik Stephen Smalley napisa?: > It has been a while since I've looked at the specifics of that policy, > but I suspect that ftpd wants to bind to arbitrary unreserved ports for > data connections. Whereas you'd like to keep the reserved port space > clean so that e.g. ftpd doesn't masquerade as some other well-known > service. Thanks for the explanation! -- ^_* From dwalsh at redhat.com Sat Mar 11 12:47:37 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 11 Mar 2006 07:47:37 -0500 Subject: Postfix/mailman problem In-Reply-To: <51703.71.129.198.222.1141407523.squirrel@71.129.198.222> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> <2117.67.111.12.103.1141339172.squirrel@67.111.12.103> <44081518.1010409@cornell.edu> <51703.71.129.198.222.1141407523.squirrel@71.129.198.222> Message-ID: <4412C6E9.80309@redhat.com> Eric Smith wrote: > Ivan wrote: > >> Yes. It seems like it's currently able to run shells (shell_exec_t). >> Doesn't appear like it can run python (bin_t). >> > > Hmmm... maybe Python should be considered a shell? From the POV of > SELinux policy, is the defining characteristic of a shell that it is > interactive, or that it runs scripts? I notice that the bash has > shell_exec_t, which csh has only bin_t. > > >> Also, I think enumerating what can be run in the postfix policy is not a >> very good idea - should have a macro instead, to be called by client >> domains. The macro would go into postfix.if. >> > > Sure, but my immediate goal is to find the simplest way to change it > such that I can turn enforcing back on again on my server. While it > would be great to do it in a correct and elegant manner, I think it's > going to be a while before I understand this stuff well enough to do > that. > > Eric > > Changes in latest policy 2.2.23-15 should allow postfix to communicate with mailman_queue_exec_t > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From hburde at t-online.de Sat Mar 11 13:30:46 2006 From: hburde at t-online.de (Holger Burde) Date: Sat, 11 Mar 2006 14:30:46 +0100 Subject: postfix high-ports prob Message-ID: <1142083846.3317.15.camel@marvin.burde-consulting.de> Hi; FC 4 currrent with targeted - up2date & unmodified. The postfix Policy or some other seems 2 prevent binding postfix to unpriv Ports > 1023 (10026 in my case). Is this intentional and if why ? Daemon based Filtering stuff needs those high-ports. Since after setting setenforce to 0 it works i think i must be policy related (the system has no source policy - so i didn't dig into that yet). Mar 11 14:06:40 proton postfix/master[3413]: fatal: bind 127.0.0.1 port 10026: Permission denied No avc denies (audit2allow) - strange and not funny .. if its policy related. PS I use some of my own RPMs (clamsmtp & anomy ..) with Postfix (FC4) & Clamav (FC4 extras) which works beside this Port Problem. Since selinux is part of my security Concept setenforce 0 is no option. hb -- --- -- - Dipl. Inform. H. Burde EMail : | From dwalsh at redhat.com Sat Mar 11 15:01:40 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Sat, 11 Mar 2006 10:01:40 -0500 Subject: postfix high-ports prob In-Reply-To: <1142083846.3317.15.camel@marvin.burde-consulting.de> References: <1142083846.3317.15.camel@marvin.burde-consulting.de> Message-ID: <4412E654.6050402@redhat.com> Holger Burde wrote: > Hi; > > FC 4 currrent with targeted - up2date & unmodified. > > The postfix Policy or some other seems 2 prevent binding postfix to > unpriv Ports > 1023 (10026 in my case). Is this intentional and if why ? > Daemon based Filtering stuff needs those high-ports. > Since after setting setenforce to 0 it works i think i must be policy > related (the system has no source policy - so i didn't dig into that > yet). > > Mar 11 14:06:40 proton postfix/master[3413]: fatal: bind 127.0.0.1 port > 10026: Permission denied > > No avc denies (audit2allow) - strange and not funny .. if its policy > related. > > PS I use some of my own RPMs (clamsmtp & anomy ..) with Postfix (FC4) & > Clamav (FC4 extras) which works beside this Port Problem. Since selinux > is part of my security Concept setenforce 0 is no option. > hb > Well you have two choices. You can update to FC5 and use some of the semanage to add additional ports to postfix. In order to get these additional audit messages in FC4 you need to install policy-sources and run a make enableaudit; make reload, you can also edit the postfix policy to allow the additional ports. You need to edit net_context file. In FC5 you can just load the enableaudit.pp policy package semodule -b /usr/share/selinux/targeted/enableaudit.pp Lots of new features in FC5 to handle local customizations. From eric at brouhaha.com Sat Mar 11 19:47:21 2006 From: eric at brouhaha.com (Eric Smith) Date: Sat, 11 Mar 2006 11:47:21 -0800 (PST) Subject: Postfix/mailman problem In-Reply-To: <4412C6E9.80309@redhat.com> References: <4562.67.111.12.176.1141263536.squirrel@67.111.12.176> <44074132.7020702@cornell.edu> <2117.67.111.12.103.1141339172.squirrel@67.111.12.103> <44081518.1010409@cornell.edu> <51703.71.129.198.222.1141407523.squirrel@71.129.198.222> <4412C6E9.80309@redhat.com> Message-ID: <56755.71.129.198.222.1142106441.squirrel@71.129.198.222> Daniel J Walsh wrote: > Changes in latest policy 2.2.23-15 should allow postfix to communicate > with mailman_queue_exec_t Thanks! I tried to build and install that on FC4 last night, but ran into too many problems with prerequisites. I was able to build many of the prerequisites, but I ran into non-obvious problems with one of them. I plan to upgrade the server to FC5 when that is released, so I'll trying installing the new policy on it at that time, since I expect I won't have nearly as much trouble with prerequisites on that. It occurs to me that the other thing that I'll eventually want to run from Postfix pipe is Spamassassin. I haven't tried that yet, but it looks like the FC4 targeted policy won't allow it. Can you please add that to a future version? Best regards, Eric From nicolas.mailhot at laposte.net Sat Mar 11 23:26:30 2006 From: nicolas.mailhot at laposte.net (Nicolas Mailhot) Date: Sun, 12 Mar 2006 00:26:30 +0100 Subject: postfix high-ports prob In-Reply-To: <4412E654.6050402@redhat.com> References: <1142083846.3317.15.camel@marvin.burde-consulting.de> <4412E654.6050402@redhat.com> Message-ID: <1142119591.2604.3.camel@rousalka.dyndns.org> Le samedi 11 mars 2006 ? 10:01 -0500, Daniel J Walsh a ?crit : > Holger Burde wrote: > > Hi; > > > > FC 4 currrent with targeted - up2date & unmodified. > > > > The postfix Policy or some other seems 2 prevent binding postfix to > > unpriv Ports > 1023 (10026 in my case). Is this intentional and if why ? > > Daemon based Filtering stuff needs those high-ports. > > Since after setting setenforce to 0 it works i think i must be policy > > related (the system has no source policy - so i didn't dig into that > > yet). > > > > Mar 11 14:06:40 proton postfix/master[3413]: fatal: bind 127.0.0.1 port > > 10026: Permission denied > > Well you have two choices. You can update to FC5 and use some of the > semanage to add additional ports > to postfix. Actually this is a postfix/filter communication problem, it works fine in FC4/5 with postfix<->amavid-new, so what you actually need is use the same ports as amavisd-new and eventually apply amavis contexts to your filter (another solution is to just use amavisd-new now it's in FE) -- Nicolas Mailhot -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 199 bytes Desc: Ceci est une partie de message num?riquement sign?e URL: From hburde at t-online.de Sun Mar 12 13:19:49 2006 From: hburde at t-online.de (Holger Burde) Date: Sun, 12 Mar 2006 14:19:49 +0100 Subject: postfix high-ports prob In-Reply-To: <4412E654.6050402@redhat.com> References: <1142083846.3317.15.camel@marvin.burde-consulting.de> <4412E654.6050402@redhat.com> Message-ID: <1142169589.3262.6.camel@marvin.burde-consulting.de> Hi; Ok - thx 4 the help. I changed the policy. Migrating to FC5 is planed but not before Release and some private testing. The FC5 selinux changes look promising! hb Am Samstag, den 11.03.2006, 10:01 -0500 schrieb Daniel J Walsh: > Holger Burde wrote: > > Hi; > > > > FC 4 currrent with targeted - up2date & unmodified. > > > > The postfix Policy or some other seems 2 prevent binding postfix to > > unpriv Ports > 1023 (10026 in my case). Is this intentional and if why ? > > Daemon based Filtering stuff needs those high-ports. > > Since after setting setenforce to 0 it works i think i must be policy > > related (the system has no source policy - so i didn't dig into that > > yet). > > > > Mar 11 14:06:40 proton postfix/master[3413]: fatal: bind 127.0.0.1 port > > 10026: Permission denied > > > > No avc denies (audit2allow) - strange and not funny .. if its policy > > related. > > > > PS I use some of my own RPMs (clamsmtp & anomy ..) with Postfix (FC4) & > > Clamav (FC4 extras) which works beside this Port Problem. Since selinux > > is part of my security Concept setenforce 0 is no option. > > hb > > > > Well you have two choices. You can update to FC5 and use some of the > semanage to add additional ports > to postfix. > > In order to get these additional audit messages in FC4 you need to > install policy-sources and run a > make enableaudit; make reload, you can also edit the postfix policy to > allow the additional ports. You need to > edit net_context file. > > In FC5 you can just load the enableaudit.pp policy package semodule -b > /usr/share/selinux/targeted/enableaudit.pp > > Lots of new features in FC5 to handle local customizations. > > > -- --- -- - Dipl. Inform. H. Burde EMail : | From hburde at t-online.de Sun Mar 12 13:30:55 2006 From: hburde at t-online.de (Holger Burde) Date: Sun, 12 Mar 2006 14:30:55 +0100 Subject: postfix high-ports prob In-Reply-To: <1142119591.2604.3.camel@rousalka.dyndns.org> References: <1142083846.3317.15.camel@marvin.burde-consulting.de> <4412E654.6050402@redhat.com> <1142119591.2604.3.camel@rousalka.dyndns.org> Message-ID: <1142170256.3262.17.camel@marvin.burde-consulting.de> Hi; Thx for the Hint (amvis ports). I stick with clamsmtp since its working quite well 4 me. Its a little C Programm without overhead (vs interpreter), no dependence flood (perl modules) and i am not so much a perl fan .... hb Am Sonntag, den 12.03.2006, 00:26 +0100 schrieb Nicolas Mailhot: > Le samedi 11 mars 2006 ? 10:01 -0500, Daniel J Walsh a ?crit : > > Holger Burde wrote: > > > Hi; > > > > > > FC 4 currrent with targeted - up2date & unmodified. > > > > > > The postfix Policy or some other seems 2 prevent binding postfix to > > > unpriv Ports > 1023 (10026 in my case). Is this intentional and if why ? > > > Daemon based Filtering stuff needs those high-ports. > > > Since after setting setenforce to 0 it works i think i must be policy > > > related (the system has no source policy - so i didn't dig into that > > > yet). > > > > > > Mar 11 14:06:40 proton postfix/master[3413]: fatal: bind 127.0.0.1 port > > > 10026: Permission denied > > > > > Well you have two choices. You can update to FC5 and use some of the > > semanage to add additional ports > > to postfix. > > Actually this is a postfix/filter communication problem, it works fine > in FC4/5 with postfix<->amavid-new, so what you actually need is use the > same ports as amavisd-new and eventually apply amavis contexts to your > filter > > (another solution is to just use amavisd-new now it's in FE) > -- --- -- - Dipl. Inform. H. Burde EMail : | From gajownik at fedora.pl Sun Mar 12 20:41:39 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Sun, 12 Mar 2006 21:41:39 +0100 Subject: What's the difference between context and fscontext mount options? Message-ID: <44148783.8040006@fedora.pl> Hi, that's me again with another lame question ;-) I've read these two articles: http://www.redhat.com/magazine/001nov04/features/selinux/ http://www.redhat.com/magazine/006apr05/features/selinux/ and now I'm a bit confused. In one of them they suggest mounting partitions with `context' option and in the other one with `fscontext'. What's the difference between these two options? They're not even mentioned in mount man page :/ Regadrs, Dawid -- ^_* From larsbj at gullik.net Mon Mar 13 13:46:47 2006 From: larsbj at gullik.net (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: 13 Mar 2006 14:46:47 +0100 Subject: selinux apache and mod_python Message-ID: I am having some difficutlies using different python libs that want to open priveledged ports on localhost or other hosts. f.ex. smtplib. What must be done SELinux wise to get this to work? I get (audit) errors like this: type=SOCKETCALL msg=audit(1142255739.103:87743): nargs=3 a0=ba1=b7cc90e0 a2=10 type=AVC msg=audit(1142256578.528:87744): avc: denied { name_connect} for pi d=16624 comm="httpd" dest=25 scontext=root:system_r:httpd_t tcontext=system_u:object_r:smtp_port_t tclass=tcp_socket type=SYSCALL msg=audit(1142256578.528:87744): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfee0760 a2=3e5114 a3=b7d290c8 items=0 pid=16624 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" -- Lgb From paul at city-fan.org Mon Mar 13 14:07:24 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Mar 2006 14:07:24 +0000 Subject: selinux apache and mod_python In-Reply-To: References: Message-ID: <44157C9C.6040800@city-fan.org> Lars Gullik Bj?nnes wrote: > I am having some difficutlies using different python libs that want to > open priveledged ports on localhost or other hosts. f.ex. smtplib. > > What must be done SELinux wise to get this to work? > > I get (audit) errors like this: > > type=SOCKETCALL msg=audit(1142255739.103:87743): nargs=3 a0=ba1=b7cc90e0 a2=10 > type=AVC msg=audit(1142256578.528:87744): avc: denied { name_connect} for pi > d=16624 comm="httpd" dest=25 scontext=root:system_r:httpd_t tcontext=system_u:object_r:smtp_port_t tclass=tcp_socket > type=SYSCALL msg=audit(1142256578.528:87744): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfee0760 a2=3e5114 a3=b7d290c8 items=0 pid=16624 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" Does this help? # setsebool httpd_can_network_connect 1 Paul. From larsbj at gullik.net Mon Mar 13 14:38:53 2006 From: larsbj at gullik.net (=?iso-8859-1?q?Lars_Gullik_Bj=F8nnes?=) Date: 13 Mar 2006 15:38:53 +0100 Subject: selinux apache and mod_python References: <44157C9C.6040800@city-fan.org> Message-ID: Paul Howarth writes: | > type=SYSCALL msg=audit(1142256578.528:87744): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfee0760 a2=3e5114 a3=b7d290c8 items=0 pid=16624 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" | | Does this help? | | # setsebool httpd_can_network_connect 1 Yes! Thanks a lot! Where can I read up on info like this so that I don't have to bother you next time? -- Lgb From paul at city-fan.org Mon Mar 13 14:57:32 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 13 Mar 2006 14:57:32 +0000 Subject: selinux apache and mod_python In-Reply-To: References: <44157C9C.6040800@city-fan.org> Message-ID: <4415885C.4060902@city-fan.org> Lars Gullik Bj?nnes wrote: > Paul Howarth writes: > > | > type=SYSCALL msg=audit(1142256578.528:87744): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfee0760 a2=3e5114 a3=b7d290c8 items=0 pid=16624 auid=500 uid=48 gid=48 euid=48 suid=48 fsuid=48 egid=48 sgid=48 fsgid=48 comm="httpd" exe="/usr/sbin/httpd" > | > | Does this help? > | > | # setsebool httpd_can_network_connect 1 > > Yes! > > Thanks a lot! Where can I read up on info like this so that I don't > have to bother you next time? man "httpd_selinux" http://fedoraproject.org/wiki/SELinux Paul. From paul at city-fan.org Tue Mar 14 10:29:29 2006 From: paul at city-fan.org (Paul Howarth) Date: Tue, 14 Mar 2006 10:29:29 +0000 Subject: SELinux Module Packaging in FC5 Message-ID: <44169B09.3050508@city-fan.org> Is there any documentation anywhere on including SELinux Policy Modules in packages (e.g. for Extras) in FC5? For instance, is there a directory where modules can be dropped into so that they get picked up aotomatically? Where should they live? Consider an example. I have an LDAP-backed addressbook frontend written in PHP that runs on apache. So I install the files in /var/www/someplace in my package and I need to provide an SELinux module that: * Includes the appropriate file contexts for the application's cache directory, which needs to be writable by httpd * Gives httpd permission to contact LDAP servers over the network (i.e. ports 389 and 636) Is it possible to turn on the httpd_builtin_scripting boolean from a module (the app is written in PHP and needs this)? Is it even sensible to try to do this, or there just be a README.SELinux telling people they need to do this themselves? Should the module be loaded in a %post script? Some guidelines would no doubt be appreciated by many people. Paul. From sds at tycho.nsa.gov Tue Mar 14 12:58:43 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 14 Mar 2006 07:58:43 -0500 Subject: SELinux Module Packaging in FC5 In-Reply-To: <44169B09.3050508@city-fan.org> References: <44169B09.3050508@city-fan.org> Message-ID: <1142341123.3713.36.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-03-14 at 10:29 +0000, Paul Howarth wrote: > Is there any documentation anywhere on including SELinux Policy Modules > in packages (e.g. for Extras) in FC5? For instance, is there a directory > where modules can be dropped into so that they get picked up > aotomatically? Where should they live? Yes, this would be useful to document in the Fedora SELinux wiki. Ideally, policy for a given software package should live in its own package on which the software package depends so that the package manager will install (and thus load) the policy before it tries to unpack the software package (thereby ensuring that any necessary file types are already defined in the kernel policy), e.g. package foo would depend on foo-policy. Not certain where the foo-policy package should drop its policy module, possibly under /usr/share/selinux/foo, and then it can install it by running semodule -i from its %post scriptlet. > Consider an example. I have an LDAP-backed addressbook frontend written > in PHP that runs on apache. So I install the files in /var/www/someplace > in my package and I need to provide an SELinux module that: > > * Includes the appropriate file contexts for the application's cache > directory, which needs to be writable by httpd > * Gives httpd permission to contact LDAP servers over the network (i.e. > ports 389 and 636) > > Is it possible to turn on the httpd_builtin_scripting boolean from a > module (the app is written in PHP and needs this)? Is it even sensible > to try to do this, or there just be a README.SELinux telling people they > need to do this themselves? Not sure if enabling the boolean is the right model there vs. "calling" an interface from your module to enable those rules unconditionally when your module is loaded, because you want the behavior reverted if/when your module is removed but other modules might likewise want the same rules or the admin may have a local customization already. The foo-policy package could certainly call setsebool -P from %post, but I doubt that is the right approach. > Should the module be loaded in a %post script? Yes, but ideally from a foo-policy package on which foo depends, so that it is loaded before unpacking foo (so that the file contexts can be set down properly). > Some guidelines would no doubt be appreciated by many people. -- Stephen Smalley National Security Agency From gajownik at fedora.pl Tue Mar 14 15:14:13 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Tue, 14 Mar 2006 16:14:13 +0100 Subject: swapfile is not automatically enabled Message-ID: <4416DDC5.2080306@fedora.pl> Hi! I see these AVC messages when system wants to enable swapfile on boot: type=AVC msg=audit(1142323714.305:7): avc: denied { getattr } for pid=1921 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811 scontext=system_u:system_r:updfstab_t tcontext=root:object_r:swapfile_t tclass=file type=AVC_PATH msg=audit(1142323714.305:7): path="/var/swapfile" OS: FC4 selinux-policy-targeted: 1.27.1-2.22 Everything works fine if I boot with `enforcing=0' kernel option. That is more, default SELinux policy in FC5 does not cause such a problems. How can I fix it? Regards, Dawid -- ^_* From dwalsh at redhat.com Tue Mar 14 15:37:37 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 14 Mar 2006 10:37:37 -0500 Subject: swapfile is not automatically enabled In-Reply-To: <4416DDC5.2080306@fedora.pl> References: <4416DDC5.2080306@fedora.pl> Message-ID: <4416E341.4040805@redhat.com> Dawid Gajownik wrote: > Hi! > > I see these AVC messages when system wants to enable swapfile on boot: > > type=AVC msg=audit(1142323714.305:7): avc: denied { getattr } for > pid=1921 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811 > scontext=system_u:system_r:updfstab_t > tcontext=root:object_r:swapfile_t tclass=file > type=AVC_PATH msg=audit(1142323714.305:7): path="/var/swapfile" > > OS: FC4 > selinux-policy-targeted: 1.27.1-2.22 > > Everything works fine if I boot with `enforcing=0' kernel option. That > is more, default SELinux policy in FC5 does not cause such a problems. > > How can I fix it? > > Regards, > Dawid > Does this cause a problem that you can see or are you just seeing the AVC message? From gajownik at fedora.pl Tue Mar 14 16:07:55 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Tue, 14 Mar 2006 17:07:55 +0100 Subject: swapfile is not automatically enabled In-Reply-To: <4416E341.4040805@redhat.com> References: <4416DDC5.2080306@fedora.pl> <4416E341.4040805@redhat.com> Message-ID: <4416EA5B.9010306@fedora.pl> Dnia 03/14/2006 04:40 PM, U?ytkownik Daniel J Walsh napisa?: > Does this cause a problem that you can see or are you just seeing the > AVC message? Well, I'm just a SELinux newbie and I may be wrong, but I think that this is a cause. I have disabled dontaudit rules in this way ? http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2827008 and I don't see other AVC messages related to swap: [root at X ~]# grep -i swap /var/log/audit/audit.log type=AVC msg=audit(1142351580.781:283): avc: denied { getattr } for pid=1918 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811 scontext=system_u:system_r:updfstab_t tcontext=root:object_r:swapfile_t tclass=file type=AVC_PATH msg=audit(1142351580.781:283): path="/var/swapfile" type=PATH msg=audit(1142351580.781:283): item=0 name="/var/swapfile" flags=0 inode=881811 dev=03:05 mode=0100600 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1142351580.941:285): avc: denied { getattr } for pid=1921 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811 scontext=system_u:system_r:updfstab_t tcontext=root:object_r:swapfile_t tclass=file type=AVC_PATH msg=audit(1142351580.941:285): path="/var/swapfile" type=PATH msg=audit(1142351580.941:285): item=0 name="/var/swapfile" flags=0 inode=881811 dev=03:05 mode=0100600 ouid=0 ogid=0 rdev=00:00 type=AVC msg=audit(1142351581.077:287): avc: denied { getattr } for pid=1925 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811 scontext=system_u:system_r:updfstab_t tcontext=root:object_r:swapfile_t tclass=file type=AVC_PATH msg=audit(1142351581.077:287): path="/var/swapfile" type=PATH msg=audit(1142351581.077:287): item=0 name="/var/swapfile" flags=0 inode=881811 dev=03:05 mode=0100600 ouid=0 ogid=0 rdev=00:00 [root at X ~]# Feel free to send me patches - I will eagerly test them :) -- ^_* From gajownik at fedora.pl Tue Mar 14 16:10:27 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Tue, 14 Mar 2006 17:10:27 +0100 Subject: SELinux and /proc In-Reply-To: <200603061159.k26BxdTf021463@tiffany.internal.tigress.co.uk> References: <200603061159.k26BxdTf021463@tiffany.internal.tigress.co.uk> Message-ID: <4416EAF3.9040507@fedora.pl> Dnia 03/06/2006 01:02 PM, U?ytkownik Ron Yorston napisa?: > I found that several processes weren't being listed by 'ps ax' when > run as an ordinary user but were when run as root. I like this feature! Unfotunately, it's disabled in new selinux-policy package :/ Would it be possible to turn it on via setsebool or semanage? Regards, Dawid -- ^_* From dwalsh at redhat.com Tue Mar 14 16:13:55 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 14 Mar 2006 11:13:55 -0500 Subject: swapfile is not automatically enabled In-Reply-To: <4416EA5B.9010306@fedora.pl> References: <4416DDC5.2080306@fedora.pl> <4416E341.4040805@redhat.com> <4416EA5B.9010306@fedora.pl> Message-ID: <4416EBC3.5090900@redhat.com> Dawid Gajownik wrote: > Dnia 03/14/2006 04:40 PM, U?ytkownik Daniel J Walsh napisa?: > >> Does this cause a problem that you can see or are you just seeing the >> AVC message? No the question was whether your swap file is working? Is it mounted? These avc messages may just need to be dontaudit'd. > > Well, I'm just a SELinux newbie and I may be wrong, but I think that > this is a cause. I have disabled dontaudit rules in this way ? > http://fedora.redhat.com/docs/selinux-faq-fc3/index.html#id2827008 > and I don't see other AVC messages related to swap: > > [root at X ~]# grep -i swap /var/log/audit/audit.log > type=AVC msg=audit(1142351580.781:283): avc: denied { getattr } for > pid=1918 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811 > scontext=system_u:system_r:updfstab_t > tcontext=root:object_r:swapfile_t tclass=file > type=AVC_PATH msg=audit(1142351580.781:283): path="/var/swapfile" > type=PATH msg=audit(1142351580.781:283): item=0 name="/var/swapfile" > flags=0 inode=881811 dev=03:05 mode=0100600 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1142351580.941:285): avc: denied { getattr } for > pid=1921 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811 > scontext=system_u:system_r:updfstab_t > tcontext=root:object_r:swapfile_t tclass=file > type=AVC_PATH msg=audit(1142351580.941:285): path="/var/swapfile" > type=PATH msg=audit(1142351580.941:285): item=0 name="/var/swapfile" > flags=0 inode=881811 dev=03:05 mode=0100600 ouid=0 ogid=0 rdev=00:00 > type=AVC msg=audit(1142351581.077:287): avc: denied { getattr } for > pid=1925 comm="fstab-sync" name="swapfile" dev=hda5 ino=881811 > scontext=system_u:system_r:updfstab_t > tcontext=root:object_r:swapfile_t tclass=file > type=AVC_PATH msg=audit(1142351581.077:287): path="/var/swapfile" > type=PATH msg=audit(1142351581.077:287): item=0 name="/var/swapfile" > flags=0 inode=881811 dev=03:05 mode=0100600 ouid=0 ogid=0 rdev=00:00 > [root at X ~]# > > Feel free to send me patches - I will eagerly test them :) > From sds at tycho.nsa.gov Tue Mar 14 16:20:13 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 14 Mar 2006 11:20:13 -0500 Subject: SELinux and /proc In-Reply-To: <4416EAF3.9040507@fedora.pl> References: <200603061159.k26BxdTf021463@tiffany.internal.tigress.co.uk> <4416EAF3.9040507@fedora.pl> Message-ID: <1142353213.3072.40.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-03-14 at 17:10 +0100, Dawid Gajownik wrote: > Dnia 03/06/2006 01:02 PM, U?ytkownik Ron Yorston napisa?: > > I found that several processes weren't being listed by 'ps ax' when > > run as an ordinary user but were when run as root. > > I like this feature! Unfotunately, it's disabled in new > selinux-policy package :/ Would it be possible to turn it on via > setsebool or semanage? What precisely did you like about it? If you use -strict or -mls policy, then unprivileged users should be restricted in what they can see in /proc (and thus ps output). For -targeted, users aren't supposed to be confined (just specific daemons), and the MCS component in -targeted is really a discretionary model, unlike MLS. -- Stephen Smalley National Security Agency From gajownik at fedora.pl Tue Mar 14 16:29:16 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Tue, 14 Mar 2006 17:29:16 +0100 Subject: swapfile is not automatically enabled In-Reply-To: <4416EBC3.5090900@redhat.com> References: <4416DDC5.2080306@fedora.pl> <4416E341.4040805@redhat.com> <4416EA5B.9010306@fedora.pl> <4416EBC3.5090900@redhat.com> Message-ID: <4416EF5C.6070502@fedora.pl> Dnia 03/14/2006 05:17 PM, U?ytkownik Daniel J Walsh napisa?: > No the question was whether your swap file is working? Is it mounted? Sorry that I did not understand your previous question. As I wrote in my first e-mail, swapfile is automatically mounted if I boot in permissive mode. In enforcing one I have to do it manually: [root at X policy]# swapon -s Filename Type Size Used Priority /dev/hda7 partition 538136 0 -1 [root at X policy]# swapon -a [root at X policy]# swapon -s Filename Type Size Used Priority /dev/hda7 partition 538136 0 -1 /var/swapfile file 126052 0 -2 [root at X policy]# -- ^_* From dwalsh at redhat.com Tue Mar 14 16:46:44 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 14 Mar 2006 11:46:44 -0500 Subject: swapfile is not automatically enabled In-Reply-To: <4416EF5C.6070502@fedora.pl> References: <4416DDC5.2080306@fedora.pl> <4416E341.4040805@redhat.com> <4416EA5B.9010306@fedora.pl> <4416EBC3.5090900@redhat.com> <4416EF5C.6070502@fedora.pl> Message-ID: <4416F374.4070004@redhat.com> Dawid Gajownik wrote: > Dnia 03/14/2006 05:17 PM, U?ytkownik Daniel J Walsh napisa?: > >> No the question was whether your swap file is working? Is it mounted? > > Sorry that I did not understand your previous question. As I wrote in > my first e-mail, swapfile is automatically mounted if I boot in > permissive mode. In enforcing one I have to do it manually: > > [root at X policy]# swapon -s > Filename Type Size Used > Priority > /dev/hda7 partition 538136 > 0 -1 > [root at X policy]# swapon -a > [root at X policy]# swapon -s > Filename Type Size Used > Priority > /dev/hda7 partition 538136 > 0 -1 > /var/swapfile file 126052 > 0 -2 > [root at X policy]# > Try ftp://people.redhat.com/dwalsh/SELinux/FC4/selinux-policy-targeted-1.27.1-2.26.noarch.rpm From gajownik at fedora.pl Tue Mar 14 18:03:13 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Tue, 14 Mar 2006 19:03:13 +0100 Subject: SELinux and /proc In-Reply-To: <1142353213.3072.40.camel@moss-spartans.epoch.ncsc.mil> References: <200603061159.k26BxdTf021463@tiffany.internal.tigress.co.uk> <4416EAF3.9040507@fedora.pl> <1142353213.3072.40.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <44170561.6060203@fedora.pl> Dnia 03/14/2006 05:18 PM, U?ytkownik Stephen Smalley napisa?: > What precisely did you like about it? Better security - user does not know what other users are doing on such a machine. > If you use -strict or -mls > policy, then unprivileged users should be restricted in what they can > see in /proc (and thus ps output). Shure, but -targeted is almost transparent to the users and it seems to be more user friendly. Actually, I have never been using -strict policy so this last part may not be true ;) > For -targeted, users aren't supposed to be confined (just specific > daemons) Yes, I know that, but you have been also experimenting lately with allow_execstack or allow_execmod booleans which break this rule ;) Why not to have another exception? This feature is so interesting that admins will rethink twice whether to disable SELinux. Regards, Dawid -- ^_* From gajownik at fedora.pl Tue Mar 14 18:03:55 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Tue, 14 Mar 2006 19:03:55 +0100 Subject: swapfile is not automatically enabled In-Reply-To: <4416F374.4070004@redhat.com> References: <4416DDC5.2080306@fedora.pl> <4416E341.4040805@redhat.com> <4416EA5B.9010306@fedora.pl> <4416EBC3.5090900@redhat.com> <4416EF5C.6070502@fedora.pl> <4416F374.4070004@redhat.com> Message-ID: <4417058B.9080506@fedora.pl> Dnia 03/14/2006 05:49 PM, U?ytkownik Daniel J Walsh napisa?: > Try > ftp://people.redhat.com/dwalsh/SELinux/FC4/selinux-policy-targeted-1.27.1-2.26.noarch.rpm These AVC messages are gone but it still does not work. You can revert these changes. Aghh, silly me. I've noticed now that auditd is turned on _after_ swap space is being enabled. In /var/log/dmesg I've found this: Adding 538136k swap on /dev/hda7. Priority:-1 extents:1 across:538136k audit(1142356803.783:2): avc: denied { read } for pid=1412 comm="swapon" name="swapfile" dev=hda5 ino=881811 scontext=system_u:system_r:fsadm_t tcontext=root:object_r:swapfile_t tclass=file SELinux: initialized (dev binfmt_misc, type binfmt_misc), uses genfs_contexts I've also noticed this on shutdown (I had to manually retype it from screen): Turning off swap: audit(1142357488.022:25): avc: denied { read write} for pid=3408 comm="swapoff" name="swapfile" dev=hda5 ino=881811 scontext=system_u:system_r:fsadm_t tcontext=root:object_t:swapfile_t tclass=file audit(some numbers): arch=40000003 syscall=115 success=no exit=-13 a0=952e390 a1=952e39c a2=bfb1f3cc a3=fbfb1feee items=1 pid=3407 audit=4294967295 uid=0 gid=0 euid=0 suid=0 fsuid=0 egid=0 sgid=0 fsgid=0 comm="swapoff" exe="/sbin/swapoff" audit(some numbers): cwd=/" audit(some numbers): item=0 name="/var/swapfile" flags=101 inode=881811 dev=03:05 mode=0100600 ouid=0 ogid=0 rdev=00:00 swapoff: /var/swapfile: Permission denied [ FAILED ] Hope that helps. -- ^_* From gajownik at fedora.pl Wed Mar 15 06:58:41 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Wed, 15 Mar 2006 07:58:41 +0100 Subject: swapfile is not automatically enabled In-Reply-To: <44171A81.8030303@redhat.com> References: <4416DDC5.2080306@fedora.pl> <44171A81.8030303@redhat.com> Message-ID: <4417BB21.5090809@fedora.pl> Dnia 03/14/06 20:36, U?ytkownik Daniel J Walsh napisa?: > Ok I put a new version out on people, see if that works and I will > update Fedora. > > ftp://people.redhat.com/dwalsh/SELinux/FC4/selinux-policy-targeted-1.27.1-2.27.noarch.rpm Thanks! It works now :D BTW maybe mailman should be configured to always send replies to fedora-selinux-list (like on other fedora-*-lists)? I quite often forget to hit "Reply All" button ;) Regards, Dawid -- ^_* From bruno at wolff.to Wed Mar 15 08:11:43 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 15 Mar 2006 02:11:43 -0600 Subject: swapfile is not automatically enabled In-Reply-To: <4417BB21.5090809@fedora.pl> References: <4416DDC5.2080306@fedora.pl> <44171A81.8030303@redhat.com> <4417BB21.5090809@fedora.pl> Message-ID: <20060315081143.GA3112@wolff.to> On Wed, Mar 15, 2006 at 07:58:41 +0100, Dawid Gajownik wrote: > > BTW maybe mailman should be configured to always send replies to > fedora-selinux-list (like on other fedora-*-lists)? I quite often forget > to hit "Reply All" button ;) The normal way to respond to lists is using reply all. The other lists are the ones that are broken. (Fortunately it isn't too hard to strip off the reply-to headers, but the lists still break the normal use of the reply-to headers.) From paul at city-fan.org Wed Mar 15 08:50:50 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 15 Mar 2006 08:50:50 +0000 Subject: swapfile is not automatically enabled In-Reply-To: <20060315081143.GA3112@wolff.to> References: <4416DDC5.2080306@fedora.pl> <44171A81.8030303@redhat.com> <4417BB21.5090809@fedora.pl> <20060315081143.GA3112@wolff.to> Message-ID: <1142412651.14260.16.camel@laurel.intra.city-fan.org> On Wed, 2006-03-15 at 02:11 -0600, Bruno Wolff III wrote: > On Wed, Mar 15, 2006 at 07:58:41 +0100, > Dawid Gajownik wrote: > > > > BTW maybe mailman should be configured to always send replies to > > fedora-selinux-list (like on other fedora-*-lists)? I quite often forget > > to hit "Reply All" button ;) > > The normal way to respond to lists is using reply all. > > The other lists are the ones that are broken. (Fortunately it isn't > too hard to strip off the reply-to headers, but the lists still break > the normal use of the reply-to headers.) The other fedora lists appear to munge the Reply-To: header such that the list address is added to any existing Reply-To: header if present, thus honouring the intent of the poster's Reply-To: header. Requiring the use of Reply-All usually results in posters getting two copies of each reply, one privately and one from the list, which I'd find really annoying if I wasn't deleting duplicate messages using procmail. I still have to go to the trouble of removing the OP's address and moving the list address from the Cc: field to the To: field whenever I reply to anything on this list. I certainly prefer the fedora-list method personally. Paul. From ejtr at layer3.co.uk Wed Mar 15 11:48:37 2006 From: ejtr at layer3.co.uk (Ted Rule) Date: Wed, 15 Mar 2006 11:48:37 +0000 Subject: The Silence of the Anacrons Message-ID: <1142423317.6433.32.camel@topaz.bugfinder.co.uk> Something that's niggled me for a while are the empty Email messages generated by Anacron. This is on FC4 / selinux-policy-strict-1.27.1-2.22 When the machine is left powered overnight, the normal /etc/cron.daily processes - including logwatch and logrotate - run perfectly happily and generate appropriate Emails. By default, logrotate doesn't result in an Email, but for reasons unrelated to SELinux I have it set to run in debug mode, so my instance does. The Email from logrotate is effectively 'sent' by /etc/cron.daily as it wrappers all the output from its child jobs. In contrast, logwatch sends its own Email independent of Cron's sendmail child process. When the machine is depowered overnight and repowered in the morning, Anacron proceeds to run the various /etc/cron.daily scripts. With SELinux enforcing, logwatch runs normally, and generates its normal Email log summary. However, logrotate's output is never seen, even though it can be seen from the various timestamps and filenames that logrotate has correctly run and suitably rotated all the logs. The overall cron.daily Job launched by Anacron results in an empty Email, with no body and more particularly no Subject. The mail From address is set to "Anacron ". Burrowing around the Anacron source it is apparent that under normal circumstances it would give the Email a subject of "Anacron job cron.daily" Given the behaviour I see, I think the problem is somehow related to the /etc/cron.daily/* processes not having rights to write to the file descriptor which is the input to Cron's overall sendmail process. I've had a look through the SELinux policy to see if I can spot the difference between the permissions of Jobs launched by Cron and Anacron, and I'm afraid I can't see where the problem lies; since jobs launched by either method appear to run as system_crond_t, the difference in behaviour eludes me. Can anyone else offer any insight into the problem? Thanks, -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From dwalsh at redhat.com Wed Mar 15 13:51:19 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 15 Mar 2006 08:51:19 -0500 Subject: The Silence of the Anacrons In-Reply-To: <1142423317.6433.32.camel@topaz.bugfinder.co.uk> References: <1142423317.6433.32.camel@topaz.bugfinder.co.uk> Message-ID: <44181BD7.5080901@redhat.com> Ted Rule wrote: > Something that's niggled me for a while are the empty Email messages > generated by Anacron. > > This is on FC4 / selinux-policy-strict-1.27.1-2.22 > > When the machine is left powered overnight, the normal /etc/cron.daily > processes - including logwatch and logrotate - run perfectly happily and > generate appropriate Emails. > > By default, logrotate doesn't result in an Email, but for reasons > unrelated to SELinux I have it set to run in debug mode, so my instance > does. The Email from logrotate is effectively 'sent' by /etc/cron.daily > as it wrappers all the output from its child jobs. > > In contrast, logwatch sends its own Email independent of Cron's sendmail > child process. > > When the machine is depowered overnight and repowered in the morning, > Anacron proceeds to run the various /etc/cron.daily scripts. With > SELinux enforcing, logwatch runs normally, and generates its normal > Email log summary. > > However, logrotate's output is never seen, even though it can be seen > from the various timestamps and filenames that logrotate has correctly > run and suitably rotated all the logs. > > The overall cron.daily Job launched by Anacron results in an empty > Email, with no body and more particularly no Subject. The mail From > address is set to "Anacron ". > > Burrowing around the Anacron source it is apparent that under normal > circumstances it would give the Email a subject of > > "Anacron job cron.daily" > > Given the behaviour I see, I think the problem is somehow related to > the /etc/cron.daily/* processes not having rights to write to the file > descriptor which is the input to Cron's overall sendmail process. > > I've had a look through the SELinux policy to see if I can spot the > difference between the permissions of Jobs launched by Cron and Anacron, > and I'm afraid I can't see where the problem lies; since jobs launched > by either method appear to run as system_crond_t, the difference in > behaviour eludes me. > > Can anyone else offer any insight into the problem? > > Thanks, > > > > Is this on FC5? If yes, are you seeing any AVC messages? If not could you attempt to enable audit semodule -b /usr/share/selinux/targeted/enableaudit.pp Create the error. Grab the AVC Messages semodule -b /usr/share/selinux/targeted/base.pp to turn off auditing again. Of course verifying this works with setenforce 0 would also help to make sure it is SELinux causing the problem. From ejtr at layer3.co.uk Wed Mar 15 15:44:28 2006 From: ejtr at layer3.co.uk (Ted Rule) Date: Wed, 15 Mar 2006 15:44:28 +0000 Subject: The Silence of the Anacrons In-Reply-To: <44181BD7.5080901@redhat.com> References: <1142423317.6433.32.camel@topaz.bugfinder.co.uk> <44181BD7.5080901@redhat.com> Message-ID: <1142437468.11026.27.camel@topaz.bugfinder.co.uk> The host is FC4 rather than FC5testN In order to avoid having to run in permissive overnight or completely reload the policy at the moment, I've run the following test: Create new directory /etc/anacron.daily and a corresponding entry in /etc/anacrontab. Create /etc/anacron.daily/0anacron and a test job /etc/anacron.daily/mailcheck. ( See below ) Run in enforcing by restarting anacron service with sudo service anacron start Wait 5 mins for Job to run, and note that the resultant Email is empty-bodied as with /etc/cron.daily Check anacron stopped. Delete the timestamp file /var/spool/anacron/anacron.daily Goto permissive with sudo setenforce 0 Wait 5 mins for Job to run, and note that the resultant Email is properly formed with Subject and body as expected. Go back to enforcing. This all seems to confirm to me that SELinux policy is somehow blanking the body and subject. The only denial messages I see during in permissive state are these: Mar 15 15:12:53 topaz sudo: ejtr : TTY=pts/1 ; PWD=/home/ejtr ; USER=root ; COMMAND=/sbin/service anacron start Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6922): avc: denied { read write } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 scontext=root:system_r:system_crond_t tcontext=user_u:object_r:user_devpts_t tclass=chr_file Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6923): avc: denied { use } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 scontext=root:system_r:system_crond_t tcontext=user_u:user_r:user_t tclass=fd which I think corresponds to the anacron processes being unable to write to the user_* FD's belonging to the shell which was used to invoke "sudo service". Since the AVC's are related to a user_* domain, I assume they are unrelated to the problem itself, which I imagine depends upon the interaction of the initrc_t, crond_t, and system_crond_t domains. I'll try and perform a similar test with an enableaudit policy as soon as I can. Obviously, the log may take a bit of weeding! ============================== $ cat /etc/anacrontab # /etc/anacrontab: configuration file for anacron # See anacron(8) and anacrontab(5) for details. SHELL=/bin/sh PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin MAILTO=root 1 5 anacron.daily run-parts /etc/anacron.daily 1 65 cron.daily run-parts /etc/cron.daily 7 70 cron.weekly run-parts /etc/cron.weekly 30 75 cron.monthly run-parts /etc/cron.monthly $ $ cat /etc/anacron.daily/0anacron #!/bin/sh # # anacron's cron script # # This script updates anacron time stamps. It is called through run-parts # either by anacron itself or by cron. # # The script is called "0anacron" to assure that it will be executed # _before_ all other scripts. anacron -u anacron.daily $ cat /etc/anacron.daily/mailcheck #!/bin/sh echo "Testing Anacron Mail system" cat /etc/resolv.conf $ On Wed, 2006-03-15 at 08:51 -0500, Daniel J Walsh wrote: > Ted Rule wrote: > > Something that's niggled me for a while are the empty Email messages > > generated by Anacron. > > > > This is on FC4 / selinux-policy-strict-1.27.1-2.22 > > > > When the machine is left powered overnight, the normal /etc/cron.daily > > processes - including logwatch and logrotate - run perfectly happily and > > generate appropriate Emails. > > > > By default, logrotate doesn't result in an Email, but for reasons > > unrelated to SELinux I have it set to run in debug mode, so my instance > > does. The Email from logrotate is effectively 'sent' by /etc/cron.daily > > as it wrappers all the output from its child jobs. > > > > In contrast, logwatch sends its own Email independent of Cron's sendmail > > child process. > > > > When the machine is depowered overnight and repowered in the morning, > > Anacron proceeds to run the various /etc/cron.daily scripts. With > > SELinux enforcing, logwatch runs normally, and generates its normal > > Email log summary. > > > > However, logrotate's output is never seen, even though it can be seen > > from the various timestamps and filenames that logrotate has correctly > > run and suitably rotated all the logs. > > > > The overall cron.daily Job launched by Anacron results in an empty > > Email, with no body and more particularly no Subject. The mail From > > address is set to "Anacron ". > > > > Burrowing around the Anacron source it is apparent that under normal > > circumstances it would give the Email a subject of > > > > "Anacron job cron.daily" > > > > Given the behaviour I see, I think the problem is somehow related to > > the /etc/cron.daily/* processes not having rights to write to the file > > descriptor which is the input to Cron's overall sendmail process. > > > > I've had a look through the SELinux policy to see if I can spot the > > difference between the permissions of Jobs launched by Cron and Anacron, > > and I'm afraid I can't see where the problem lies; since jobs launched > > by either method appear to run as system_crond_t, the difference in > > behaviour eludes me. > > > > Can anyone else offer any insight into the problem? > > > > Thanks, > > > > > > > > > Is this on FC5? If yes, are you seeing any AVC messages? If not could > you attempt to enable audit > > semodule -b /usr/share/selinux/targeted/enableaudit.pp > > Create the error. > > Grab the AVC Messages > > semodule -b /usr/share/selinux/targeted/base.pp > > to turn off auditing again. > > > Of course verifying this works with setenforce 0 would also help to make > sure it is SELinux causing the problem. > -- Ted Rule Director, Layer3 Systems Ltd W: http://www.layer3.co.uk/ From udjinrg at forenet.by Wed Mar 15 17:08:26 2006 From: udjinrg at forenet.by (Maxim Britov) Date: Wed, 15 Mar 2006 19:08:26 +0200 Subject: fc5: several troubles at my first attempt Message-ID: <20060315190826.493b66a0@maxim-l.office.modum.by> I have installed current fc5 by http about week or two ago. It updated from rawhide. It currently installed on hda2 and it ran from qemu. I see many avc denied messages in dmesg (repeated 210 times with different pids): audit(1142439027.188:2): avc: denied { search } for pid=349 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir hda2 here is / It can't mount /var/spool/squid at boot time. dmesg is: audit(1142439059.662:212): avc: denied { mounton } for pid=820 comm="mount" name="squid" dev=hda7 ino=261122 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:squid_cache_t:s0 tclass=dir hda7 here is /var After booting I can mount it with: # mount /var/spool/squid (/etc/fstab uses default options): "kjournald starting. Commit interval 5 seconds EXT3 FS on hda5, internal journal EXT3-fs: mounted filesystem with ordered data mode. SELinux: initialized (dev hda5, type ext3), uses xattr" I can't switch to strict mode. I did it by editing /etc/selinux/config and touch /.autorelabel System can't boot after restarting: many avc denied for init_t, etc. Where I wrong? security: 5 users, 5 roles, 1555 types, 68 bools, 1 sens, 256 cats security: 55 classes, 89189 rules SELinux: Completing initialization. SELinux: Setting up existing superblocks. SELinux: initialized (dev hda2, type ext3), uses xattr SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev debugfs, type debugfs), uses genfs_contexts SELinux: initialized (dev selinuxfs, type selinuxfs), uses genfs_contexts SELinux: initialized (dev mqueue, type mqueue), uses transition SIDs SELinux: initialized (dev hugetlbfs, type hugetlbfs), uses genfs_contexts SELinux: initialized (dev devpts, type devpts), uses transition SIDs SELinux: initialized (dev eventpollfs, type eventpollfs), uses genfs_contexts SELinux: initialized (dev inotifyfs, type inotifyfs), uses genfs_contexts SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs SELinux: initialized (dev futexfs, type futexfs), uses genfs_contexts SELinux: initialized (dev pipefs, type pipefs), uses task SIDs SELinux: initialized (dev sockfs, type sockfs), uses task SIDs SELinux: initialized (dev proc, type proc), uses genfs_contexts SELinux: initialized (dev bdev, type bdev), uses genfs_contexts SELinux: initialized (dev rootfs, type rootfs), uses genfs_contexts SELinux: initialized (dev sysfs, type sysfs), uses genfs_contexts audit(1142442162.184:2): avc: denied { search } for pid=1 comm="init" name="lib" dev=hda2 ino=775681 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=dir audit(1142442162.188:3): avc: denied { read } for pid=1 comm="init" name="ld-linux.so.2" dev=hda2 ino=775935 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:lib_t:s0 tclass=lnk_file audit(1142442162.188:4): avc: denied { execute } for pid=1 comm="init" name="ld-2.4.so" dev=hda2 ino=775682 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:ld_so_t:s0 tclass=file audit(1142442162.188:5): avc: denied { read } for pid=1 comm="init" name="ld-2.4.so" dev=hda2 ino=775682 scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:object_r:ld_so_t:s0 tclass=file SELinux: initialized (dev usbfs, type usbfs), uses genfs_contexts audit(1142442163.580:6): avc: denied { sigchld } for pid=1 comm="init" scontext=system_u:system_r:kernel_t:s0 tcontext=system_u:system_r:init_t:s0 tclass=process audit(1142442169.142:7): avc: denied { execute } for pid=325 comm="udevd" name="udev_run_hotplugd" dev=hda2 ino=775731 scontext=system_u:system_r:udev_t:s0-s0:c0.c255 tcontext=system_u:object_r:lib_t:s0 tclass=file audit(1142442169.142:8): avc: denied { execute_no_trans } for pid=325 comm="udevd" name="udev_run_hotplugd" dev=hda2 ino=775731 scontext=system_u:system_r:udev_t:s0-s0:c0.c255 tcontext=system_u:object_r:lib_t:s0 tclass=file audit(1142442171.434:9): avc: denied { search } for pid=364 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir ......... Please excuse me for my engrish :) -- Maxim Britov GnuPG KeyID 0x4580A6D66F3DB1FB xmpp:maxim at modum.by icq 198171258 Fingerprint: 4059 B5C5 8985 5A47 8F5A 8623 4580 A6D6 6F3D B1FB GnuPG-ru Team (http://lists.gnupg.org/mailman/listinfo/gnupg-ru xmpp:gnupg-ru at conference.jabber.ru) From sds at tycho.nsa.gov Wed Mar 15 17:26:25 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Mar 2006 12:26:25 -0500 Subject: fc5: several troubles at my first attempt In-Reply-To: <20060315190826.493b66a0@maxim-l.office.modum.by> References: <20060315190826.493b66a0@maxim-l.office.modum.by> Message-ID: <1142443585.4933.22.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-15 at 19:08 +0200, Maxim Britov wrote: > I have installed current fc5 by http about week or two ago. It updated from rawhide. > It currently installed on hda2 and it ran from qemu. > > I see many avc denied messages in dmesg (repeated 210 times with different pids): > audit(1142439027.188:2): avc: denied { search } for pid=349 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir > hda2 here is / Hmmm.../var should be labeled with system_u:object_r:var_t, not file_t. Need to relabel? > It can't mount /var/spool/squid at boot time. dmesg is: > audit(1142439059.662:212): avc: denied { mounton } for pid=820 comm="mount" name="squid" dev=hda7 ino=261122 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:squid_cache_t:s0 tclass=dir Might not be included in the current policy. > hda7 here is /var > After booting I can mount it with: # mount /var/spool/squid (/etc/fstab uses default options): > "kjournald starting. Commit interval 5 seconds > EXT3 FS on hda5, internal journal > EXT3-fs: mounted filesystem with ordered data mode. > SELinux: initialized (dev hda5, type ext3), uses xattr" > > I can't switch to strict mode. > I did it by editing /etc/selinux/config and touch /.autorelabel Strict policy (i.e. SELINUXTYPE=strict) or enforcing mode (i.e. SELINUX=enforcing)? You want SELINUXTYPE=targeted, SELINUX=enforcing. Boot with enforcing=0 if you need to temporarily boot permissive to recover. Boot with enforcing=0 autorelabel to force a relabel. -- Stephen Smalley National Security Agency From smooge at gmail.com Wed Mar 15 17:30:03 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 15 Mar 2006 10:30:03 -0700 Subject: swapfile is not automatically enabled In-Reply-To: <1142412651.14260.16.camel@laurel.intra.city-fan.org> References: <4416DDC5.2080306@fedora.pl> <44171A81.8030303@redhat.com> <4417BB21.5090809@fedora.pl> <20060315081143.GA3112@wolff.to> <1142412651.14260.16.camel@laurel.intra.city-fan.org> Message-ID: <80d7e4090603150930r1782cc75wa81566ee579767d7@mail.gmail.com> On 3/15/06, Paul Howarth wrote: > On Wed, 2006-03-15 at 02:11 -0600, Bruno Wolff III wrote: > > On Wed, Mar 15, 2006 at 07:58:41 +0100, > > Dawid Gajownik wrote: > > > > > > BTW maybe mailman should be configured to always send replies to > > > fedora-selinux-list (like on other fedora-*-lists)? I quite often forget > > > to hit "Reply All" button ;) > > > > The normal way to respond to lists is using reply all. > > > > The other lists are the ones that are broken. (Fortunately it isn't > > too hard to strip off the reply-to headers, but the lists still break > > the normal use of the reply-to headers.) > > The other fedora lists appear to munge the Reply-To: header such that > the list address is added to any existing Reply-To: header if present, > thus honouring the intent of the poster's Reply-To: header. > I think it all comes down to different societal etiquettes. I have seen this a lot in mergers of organizations and companies. Both sides claim that the proper way to run mailling lists is either to "Reply-To-All" by mailling list or manually. They each come up with straw men arguments since there doesnt seem to be a IETF RFC on mailing list management. I personally find it all to be at the level of religous arguments about how many times to genuflect and at what. Misses the whole purpose and just causes people to figure out who their "clan" is. -- Stephen J Smoogen. CSIRT/Linux System Administrator From smooge at gmail.com Wed Mar 15 17:32:02 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 15 Mar 2006 10:32:02 -0700 Subject: fc5: several troubles at my first attempt In-Reply-To: <1142443585.4933.22.camel@moss-spartans.epoch.ncsc.mil> References: <20060315190826.493b66a0@maxim-l.office.modum.by> <1142443585.4933.22.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <80d7e4090603150932q2bbba97bga4767ffb6e648619@mail.gmail.com> On 3/15/06, Stephen Smalley wrote: > On Wed, 2006-03-15 at 19:08 +0200, Maxim Britov wrote: > > I have installed current fc5 by http about week or two ago. It updated from rawhide. > > It currently installed on hda2 and it ran from qemu. > > > > I see many avc denied messages in dmesg (repeated 210 times with different pids): > > audit(1142439027.188:2): avc: denied { search } for pid=349 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir > > hda2 here is / Hi Maxim. There was a policy that had some issues in it.. that caused me all kind of grief. I needed to do a relabel as single user to fix the problem. -- Stephen J Smoogen. CSIRT/Linux System Administrator From sds at tycho.nsa.gov Wed Mar 15 17:55:19 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Mar 2006 12:55:19 -0500 Subject: fc5: several troubles at my first attempt In-Reply-To: <1142443585.4933.22.camel@moss-spartans.epoch.ncsc.mil> References: <20060315190826.493b66a0@maxim-l.office.modum.by> <1142443585.4933.22.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1142445319.4933.35.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-15 at 12:26 -0500, Stephen Smalley wrote: > On Wed, 2006-03-15 at 19:08 +0200, Maxim Britov wrote: > > I have installed current fc5 by http about week or two ago. It updated from rawhide. > > It currently installed on hda2 and it ran from qemu. > > > > I see many avc denied messages in dmesg (repeated 210 times with different pids): > > audit(1142439027.188:2): avc: denied { search } for pid=349 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir > > hda2 here is / > > Hmmm.../var should be labeled with system_u:object_r:var_t, not file_t. > Need to relabel? > > > It can't mount /var/spool/squid at boot time. dmesg is: > > audit(1142439059.662:212): avc: denied { mounton } for pid=820 comm="mount" name="squid" dev=hda7 ino=261122 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:squid_cache_t:s0 tclass=dir > > Might not be included in the current policy. > > > hda7 here is /var > > After booting I can mount it with: # mount /var/spool/squid (/etc/fstab uses default options): > > "kjournald starting. Commit interval 5 seconds > > EXT3 FS on hda5, internal journal > > EXT3-fs: mounted filesystem with ordered data mode. > > SELinux: initialized (dev hda5, type ext3), uses xattr" > > > > I can't switch to strict mode. > > I did it by editing /etc/selinux/config and touch /.autorelabel > > Strict policy (i.e. SELINUXTYPE=strict) or enforcing mode (i.e. > SELINUX=enforcing)? You want SELINUXTYPE=targeted, SELINUX=enforcing. > Boot with enforcing=0 if you need to temporarily boot permissive to > recover. Boot with enforcing=0 autorelabel to force a relabel. I believe that the (highly modular) strict policy is known to be broken in fc5/rawhide because of the file contexts ordering issue, which requires further changes to libsemanage. Right, Dan? So only -targeted or -mls are in a working state. Possibly that -strict policy shouldn't be included in fc5 since it is known to be broken? -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Mar 15 17:58:54 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Mar 2006 12:58:54 -0500 Subject: fc5: several troubles at my first attempt In-Reply-To: <1142445319.4933.35.camel@moss-spartans.epoch.ncsc.mil> References: <20060315190826.493b66a0@maxim-l.office.modum.by> <1142443585.4933.22.camel@moss-spartans.epoch.ncsc.mil> <1142445319.4933.35.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1142445534.4933.40.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-15 at 12:55 -0500, Stephen Smalley wrote: > I believe that the (highly modular) strict policy is known to be broken > in fc5/rawhide because of the file contexts ordering issue, which > requires further changes to libsemanage. Right, Dan? So only -targeted > or -mls are in a working state. Possibly that -strict policy shouldn't > be included in fc5 since it is known to be broken? Another option btw would be to put everything into the base module for -strict as is being done for -targeted and -mls already, right? That would at least provide a working -strict policy for fc5. -- Stephen Smalley National Security Agency From csellers at tresys.com Wed Mar 15 18:54:10 2006 From: csellers at tresys.com (Chad Sellers) Date: Wed, 15 Mar 2006 13:54:10 -0500 Subject: fc5: several troubles at my first attempt In-Reply-To: <1142445534.4933.40.camel@moss-spartans.epoch.ncsc.mil> References: <20060315190826.493b66a0@maxim-l.office.modum.by> <1142443585.4933.22.camel@moss-spartans.epoch.ncsc.mil> <1142445319.4933.35.camel@moss-spartans.epoch.ncsc.mil> <1142445534.4933.40.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <441862D2.7010500@tresys.com> Stephen Smalley wrote: > On Wed, 2006-03-15 at 12:55 -0500, Stephen Smalley wrote: >> I believe that the (highly modular) strict policy is known to be broken >> in fc5/rawhide because of the file contexts ordering issue, which >> requires further changes to libsemanage. Right, Dan? So only -targeted >> or -mls are in a working state. Possibly that -strict policy shouldn't >> be included in fc5 since it is known to be broken? > > Another option btw would be to put everything into the base module for > -strict as is being done for -targeted and -mls already, right? That > would at least provide a working -strict policy for fc5. > Yes, that's an option, though I'd lean against it. To my knowledge, we still haven't come up with a good method for splitting things out into their own modules. So, throwing everything into base now would make it difficult to split them out later. I'd lean toward not including strict on the CD and putting it in repos once it's working, but I'm not sure how permissible that is (I'm guessing we have to have the package in FC5 in order to make updates to it). Chad -- ---------------------- Chad Sellers Tresys Technology, LLC csellers at tresys.com http://www.tresys.com From bruno at wolff.to Wed Mar 15 19:03:30 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Wed, 15 Mar 2006 13:03:30 -0600 Subject: swapfile is not automatically enabled In-Reply-To: <1142412651.14260.16.camel@laurel.intra.city-fan.org> References: <4416DDC5.2080306@fedora.pl> <44171A81.8030303@redhat.com> <4417BB21.5090809@fedora.pl> <20060315081143.GA3112@wolff.to> <1142412651.14260.16.camel@laurel.intra.city-fan.org> Message-ID: <20060315190330.GA9989@wolff.to> On Wed, Mar 15, 2006 at 08:50:50 +0000, Paul Howarth wrote: > On Wed, 2006-03-15 at 02:11 -0600, Bruno Wolff III wrote: > > > > The other lists are the ones that are broken. (Fortunately it isn't > > too hard to strip off the reply-to headers, but the lists still break > > the normal use of the reply-to headers.) > > The other fedora lists appear to munge the Reply-To: header such that > the list address is added to any existing Reply-To: header if present, > thus honouring the intent of the poster's Reply-To: header. That's what I meant by broken. I strip the bogus reply-to headers. Replying to the list when you mean to reply to an indivual in private is usually a worse mistake than the converse. > Requiring the use of Reply-All usually results in posters getting two > copies of each reply, one privately and one from the list, which I'd > find really annoying if I wasn't deleting duplicate messages using > procmail. I still have to go to the trouble of removing the OP's address > and moving the list address from the Cc: field to the To: field whenever You can use mail-followup-to to specify that followups shouldn't to you directly. Some list processing software can also detect that you are cc'd and not send you a copy from the list in that case. A second copy of a message directly to you can have benefits in some cases. Particular examples are when the lists are slow and when you want to filter messages sent to you separately for special attention. From sds at tycho.nsa.gov Wed Mar 15 19:20:44 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 15 Mar 2006 14:20:44 -0500 Subject: swapfile is not automatically enabled In-Reply-To: <80d7e4090603150930r1782cc75wa81566ee579767d7@mail.gmail.com> References: <4416DDC5.2080306@fedora.pl> <44171A81.8030303@redhat.com> <4417BB21.5090809@fedora.pl> <20060315081143.GA3112@wolff.to> <1142412651.14260.16.camel@laurel.intra.city-fan.org> <80d7e4090603150930r1782cc75wa81566ee579767d7@mail.gmail.com> Message-ID: <1142450444.4933.67.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-15 at 10:30 -0700, Stephen J. Smoogen wrote: > I think it all comes down to different societal etiquettes. I have > seen this a lot in mergers of organizations and companies. Both sides > claim that the proper way to run mailling lists is either to > "Reply-To-All" by mailling list or manually. They each come up with > straw men arguments since there doesnt seem to be a IETF RFC on > mailing list management. > > I personally find it all to be at the level of religous arguments > about how many times to genuflect and at what. Misses the whole > purpose and just causes people to figure out who their "clan" is. Summarized nicely by: http://www.unicom.com/pw/reply-to-harmful.html versus http://www.metasystema.net/essays/reply-to.mhtml Of course, the first opinion is the correct one ;) -- Stephen Smalley National Security Agency From Valdis.Kletnieks at vt.edu Wed Mar 15 22:24:02 2006 From: Valdis.Kletnieks at vt.edu (Valdis.Kletnieks at vt.edu) Date: Wed, 15 Mar 2006 17:24:02 -0500 Subject: Strict policy tweak for homedir_template Message-ID: <200603152224.k2FMO2D6031270@turing-police.cc.vt.edu> selinux-policy-strict-2.2.23-15 I couldn't figure out why stuff in ~/.ssh was getting set to user_home_t rather than user_home_ssh_t. I had to do the following patch (to make more-specifics come later) and re-run genhomedircon before restorecon and friends started DTRT... --- homedir_template.dist 2006-03-15 16:05:28.000000000 -0500 +++ homedir_template 2006-03-15 17:18:02.000000000 -0500 @@ -2,6 +2,7 @@ HOME_ROOT -d system_u:object_r:home_root_t:s0 HOME_ROOT/\.journal <> HOME_ROOT/lost\+found -d system_u:object_r:lost_found_t:s0 +HOME_DIR/.+ system_u:object_r:ROLE_home_t:s0 HOME_DIR/((www)|(web)|(public_html))(/.+)? system_u:object_r:httpd_ROLE_content_t:s0 HOME_DIR/\.gnupg(/.+)? system_u:object_r:ROLE_gpg_secret_t:s0 HOME_DIR/\.ircmotd -- system_u:object_r:ROLE_irc_home_t:s0 @@ -12,7 +13,6 @@ HOME_DIR/\.ssh(/.*)? system_u:object_r:ROLE_home_ssh_t:s0 HOME_DIR/\.uml(/.*)? system_u:object_r:ROLE_uml_rw_t:s0 HOME_DIR -d system_u:object_r:ROLE_home_dir_t:s0 -HOME_DIR/.+ system_u:object_r:ROLE_home_t:s0 HOME_DIR/\.ICEauthority.* -- system_u:object_r:ROLE_iceauth_home_t:s0 HOME_DIR/\.xauth.* -- system_u:object_r:ROLE_xauth_home_t:s0 HOME_DIR/\.Xauthority.* -- system_u:object_r:ROLE_xauth_home_t:s0 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 228 bytes Desc: not available URL: From udjinrg at forenet.by Thu Mar 16 09:19:33 2006 From: udjinrg at forenet.by (Maxim Britov) Date: Thu, 16 Mar 2006 11:19:33 +0200 Subject: fc5: several troubles at my first attempt In-Reply-To: <20060315190826.493b66a0@maxim-l.office.modum.by> References: <20060315190826.493b66a0@maxim-l.office.modum.by> Message-ID: <20060316111933.17a04a08@maxim-l.office.modum.by> On Wed, 15 Mar 2006 19:08:26 +0200 Maxim Britov wrote: > I have installed current fc5 by http about week or two ago. It updated from rawhide. > It currently installed on hda2 and it ran from qemu. > > I see many avc denied messages in dmesg (repeated 210 times with different pids): > audit(1142439027.188:2): avc: denied { search } for pid=349 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir > hda2 here is / This problem was resolved. Root filesystem had unlabeled /var Relabel work after mount all only. I had to do: umount /var ; restorecon /var ; reboot -- Maxim Britov GnuPG KeyID 0x4580A6D66F3DB1FB xmpp:maxim at modum.by icq 198171258 Fingerprint: 4059 B5C5 8985 5A47 8F5A 8623 4580 A6D6 6F3D B1FB GnuPG-ru Team (http://lists.gnupg.org/mailman/listinfo/gnupg-ru xmpp:gnupg-ru at conference.jabber.ru) From dwalsh at redhat.com Thu Mar 16 14:43:14 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 16 Mar 2006 09:43:14 -0500 Subject: fc5: several troubles at my first attempt In-Reply-To: <1142445319.4933.35.camel@moss-spartans.epoch.ncsc.mil> References: <20060315190826.493b66a0@maxim-l.office.modum.by> <1142443585.4933.22.camel@moss-spartans.epoch.ncsc.mil> <1142445319.4933.35.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <44197982.8090902@redhat.com> Stephen Smalley wrote: > On Wed, 2006-03-15 at 12:26 -0500, Stephen Smalley wrote: > >> On Wed, 2006-03-15 at 19:08 +0200, Maxim Britov wrote: >> >>> I have installed current fc5 by http about week or two ago. It updated from rawhide. >>> It currently installed on hda2 and it ran from qemu. >>> >>> I see many avc denied messages in dmesg (repeated 210 times with different pids): >>> audit(1142439027.188:2): avc: denied { search } for pid=349 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir >>> hda2 here is / >>> >> Hmmm.../var should be labeled with system_u:object_r:var_t, not file_t. >> Need to relabel? >> >> >>> It can't mount /var/spool/squid at boot time. dmesg is: >>> audit(1142439059.662:212): avc: denied { mounton } for pid=820 comm="mount" name="squid" dev=hda7 ino=261122 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:squid_cache_t:s0 tclass=dir >>> >> Might not be included in the current policy. >> >> >>> hda7 here is /var >>> After booting I can mount it with: # mount /var/spool/squid (/etc/fstab uses default options): >>> "kjournald starting. Commit interval 5 seconds >>> EXT3 FS on hda5, internal journal >>> EXT3-fs: mounted filesystem with ordered data mode. >>> SELinux: initialized (dev hda5, type ext3), uses xattr" >>> >>> I can't switch to strict mode. >>> I did it by editing /etc/selinux/config and touch /.autorelabel >>> >> Strict policy (i.e. SELINUXTYPE=strict) or enforcing mode (i.e. >> SELINUX=enforcing)? You want SELINUXTYPE=targeted, SELINUX=enforcing. >> Boot with enforcing=0 if you need to temporarily boot permissive to >> recover. Boot with enforcing=0 autorelabel to force a relabel. >> > > I believe that the (highly modular) strict policy is known to be broken > in fc5/rawhide because of the file contexts ordering issue, which > requires further changes to libsemanage. Right, Dan? So only -targeted > or -mls are in a working state. Possibly that -strict policy shouldn't > be included in fc5 since it is known to be broken? > > Yes. strict is broken, until we can update the tool chain. Which can begin shortly after we ship FC5. From dwalsh at redhat.com Thu Mar 16 18:22:31 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 16 Mar 2006 13:22:31 -0500 Subject: The Silence of the Anacrons In-Reply-To: <1142437468.11026.27.camel@topaz.bugfinder.co.uk> References: <1142423317.6433.32.camel@topaz.bugfinder.co.uk> <44181BD7.5080901@redhat.com> <1142437468.11026.27.camel@topaz.bugfinder.co.uk> Message-ID: <4419ACE7.5080407@redhat.com> Ted Rule wrote: > The host is FC4 rather than FC5testN > > In order to avoid having to run in permissive overnight or completely > reload the policy at the moment, I've run the following test: > > Create new directory /etc/anacron.daily and a corresponding entry > in /etc/anacrontab. Create /etc/anacron.daily/0anacron and a test > job /etc/anacron.daily/mailcheck. ( See below ) > > Run in enforcing by restarting anacron service with > > sudo service anacron start > > Wait 5 mins for Job to run, and note that the resultant Email is > empty-bodied as with /etc/cron.daily > > Check anacron stopped. > > Delete the timestamp file /var/spool/anacron/anacron.daily > > Goto permissive with > > sudo setenforce 0 > > Wait 5 mins for Job to run, and note that the resultant Email is > properly formed with Subject and body as expected. > > Go back to enforcing. > > This all seems to confirm to me that SELinux policy is somehow blanking > the body and subject. The only denial messages I see during in > permissive state are these: > > Mar 15 15:12:53 topaz sudo: ejtr : TTY=pts/1 ; PWD=/home/ejtr ; > USER=root ; COMMAND=/sbin/service anacron start > Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6922): avc: denied > { read write } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 > scontext=root:system_r:system_crond_t > tcontext=user_u:object_r:user_devpts_t tclass=chr_file > Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6923): avc: denied > { use } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 > scontext=root:system_r:system_crond_t tcontext=user_u:user_r:user_t > tclass=fd > > which I think corresponds to the anacron processes being unable to write > to the user_* FD's belonging to the shell which was used to invoke "sudo > service". Since the AVC's are related to a user_* domain, I assume they > are unrelated to the problem itself, which I imagine depends upon the > interaction of the initrc_t, crond_t, and system_crond_t domains. > > I'll try and perform a similar test with an enableaudit policy as soon > as I can. Obviously, the log may take a bit of weeding! > > > ============================== > $ cat /etc/anacrontab > # /etc/anacrontab: configuration file for anacron > > # See anacron(8) and anacrontab(5) for details. > > SHELL=/bin/sh > PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin > MAILTO=root > > 1 5 anacron.daily run-parts /etc/anacron.daily > 1 65 cron.daily run-parts /etc/cron.daily > 7 70 cron.weekly run-parts /etc/cron.weekly > 30 75 cron.monthly run-parts /etc/cron.monthly > $ > > $ cat /etc/anacron.daily/0anacron > #!/bin/sh > # > # anacron's cron script > # > # This script updates anacron time stamps. It is called through > run-parts > # either by anacron itself or by cron. > # > # The script is called "0anacron" to assure that it will be executed > # _before_ all other scripts. > > anacron -u anacron.daily > > $ cat /etc/anacron.daily/mailcheck > #!/bin/sh > > echo "Testing Anacron Mail system" > > cat /etc/resolv.conf > > $ > Please enter a bugzilla so we don't loose this. > > > On Wed, 2006-03-15 at 08:51 -0500, Daniel J Walsh wrote: > >> Ted Rule wrote: >> >>> Something that's niggled me for a while are the empty Email messages >>> generated by Anacron. >>> >>> This is on FC4 / selinux-policy-strict-1.27.1-2.22 >>> >>> When the machine is left powered overnight, the normal /etc/cron.daily >>> processes - including logwatch and logrotate - run perfectly happily and >>> generate appropriate Emails. >>> >>> By default, logrotate doesn't result in an Email, but for reasons >>> unrelated to SELinux I have it set to run in debug mode, so my instance >>> does. The Email from logrotate is effectively 'sent' by /etc/cron.daily >>> as it wrappers all the output from its child jobs. >>> >>> In contrast, logwatch sends its own Email independent of Cron's sendmail >>> child process. >>> >>> When the machine is depowered overnight and repowered in the morning, >>> Anacron proceeds to run the various /etc/cron.daily scripts. With >>> SELinux enforcing, logwatch runs normally, and generates its normal >>> Email log summary. >>> >>> However, logrotate's output is never seen, even though it can be seen >>> from the various timestamps and filenames that logrotate has correctly >>> run and suitably rotated all the logs. >>> >>> The overall cron.daily Job launched by Anacron results in an empty >>> Email, with no body and more particularly no Subject. The mail From >>> address is set to "Anacron ". >>> >>> Burrowing around the Anacron source it is apparent that under normal >>> circumstances it would give the Email a subject of >>> >>> "Anacron job cron.daily" >>> >>> Given the behaviour I see, I think the problem is somehow related to >>> the /etc/cron.daily/* processes not having rights to write to the file >>> descriptor which is the input to Cron's overall sendmail process. >>> >>> I've had a look through the SELinux policy to see if I can spot the >>> difference between the permissions of Jobs launched by Cron and Anacron, >>> and I'm afraid I can't see where the problem lies; since jobs launched >>> by either method appear to run as system_crond_t, the difference in >>> behaviour eludes me. >>> >>> Can anyone else offer any insight into the problem? >>> >>> Thanks, >>> >>> >>> >>> >>> >> Is this on FC5? If yes, are you seeing any AVC messages? If not could >> you attempt to enable audit >> >> semodule -b /usr/share/selinux/targeted/enableaudit.pp >> >> Create the error. >> >> Grab the AVC Messages >> >> semodule -b /usr/share/selinux/targeted/base.pp >> >> to turn off auditing again. >> >> >> Of course verifying this works with setenforce 0 would also help to make >> sure it is SELinux causing the problem. >> >> > > From bruno at wolff.to Sat Mar 18 18:49:24 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 18 Mar 2006 12:49:24 -0600 Subject: autorelabel and sym links Message-ID: <20060318184924.GA4504@wolff.to> When a file system is relabelled, how are files pointed to by sym links affected? I can think of several different ways they may be handled, but I haven't found any clear cut documentation on this subject. Similarly how does restorecon -R behave? Currently the man page is silent, but a google search turned up a change log entry suggesting it doesn't follow sym links. From bleher at informatik.uni-muenchen.de Sun Mar 19 00:07:18 2006 From: bleher at informatik.uni-muenchen.de (Thomas Bleher) Date: Sun, 19 Mar 2006 01:07:18 +0100 Subject: autorelabel and sym links In-Reply-To: <20060318184924.GA4504@wolff.to> References: <20060318184924.GA4504@wolff.to> Message-ID: <20060319000717.GF8157@thorium.jmh.mhn.de> * Bruno Wolff III [2006-03-18 19:48]: > When a file system is relabelled, how are files pointed to by sym links > affected? I can think of several different ways they may be handled, but > I haven't found any clear cut documentation on this subject. Symlinks have security contexts like any other filesystem object. The relabel process doesn't look at the file the symlinks points to but just relabels the link according to the place it lives in the filesystem. If you look at the file_contexts file you'll notice that it is also possible to set the context depending on filesystem object type. Eg the line > /vmlinuz.* -l gen_context(system_u:object_r:boot_t,s0) will result in everything starting with /vmlinuz being labeled as system_u:object_r:boot_t, but only if it is a symlink (see the -l). The possible values are: -- regular file -d directory -s socket file -p named pipe -c char device file -b block device file > Similarly how does restorecon -R behave? Currently the man page is silent, > but a google search turned up a change log entry suggesting it doesn't > follow sym links. That's true. restorecon doesn't need (and isn't allowed to by policy) to read where symlinks point to. This is very helpful in preventing symlink attacks. Hardlinks are more problematic. Setfiles (which runs when the whole filesystem is relabeled) keeps track of hardlinks and warns if a file would get two different security contexts because of its different file names. I don't know if restorecon has a similar check but it cannot reliably detect this problem if it's only run on part of a filesystem. This is the reason you should (on targeted policy) never run restorecon on untrusted userdata. Thomas -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 189 bytes Desc: Digital signature URL: From bruno at wolff.to Sun Mar 19 04:46:25 2006 From: bruno at wolff.to (Bruno Wolff III) Date: Sat, 18 Mar 2006 22:46:25 -0600 Subject: autorelabel and sym links In-Reply-To: <20060319000717.GF8157@thorium.jmh.mhn.de> References: <20060318184924.GA4504@wolff.to> <20060319000717.GF8157@thorium.jmh.mhn.de> Message-ID: <20060319044625.GA12868@wolff.to> On Sun, Mar 19, 2006 at 01:07:18 +0100, Thomas Bleher wrote: > > That's true. restorecon doesn't need (and isn't allowed to by policy) to > read where symlinks point to. This is very helpful in preventing symlink > attacks. > Hardlinks are more problematic. Setfiles (which runs when the whole > filesystem is relabeled) keeps track of hardlinks and warns if a file > would get two different security contexts because of its different file > names. I don't know if restorecon has a similar check but it cannot > reliably detect this problem if it's only run on part of a filesystem. > This is the reason you should (on targeted policy) never run restorecon > on untrusted userdata. Thanks that was very helpful. I didn't know that setfiles was what was used to relabel filesystems. Its man page is pretty clear on what it does. From dragoran at feuerpokemon.de Sun Mar 19 10:55:18 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 19 Mar 2006 11:55:18 +0100 Subject: turing off selinux makes gnome 60% faster? Message-ID: <441D3896.6000205@feuerpokemon.de> according to this review: http://distrocenter.linux.com/distrocenter/06/03/08/2321254.shtml?tid=107 "FC5 runs on a 2.6.15 kernel and uses a branded version of GNOME 2.14 as its default desktop. Although GNOME 2.14 is roughly twice as fast as earlier versions when installed in other distributions, little of this acceleration is visible in FC5. A large part of this relative slowness is due to the default enabling of SELinux -- turn it off, and GNOME is as much as 60% faster." turing off selinux makes gnome 60% faster... can this be true? how does selinux affects gnome perfomance? From dragoran at feuerpokemon.de Sun Mar 19 11:03:55 2006 From: dragoran at feuerpokemon.de (dragoran) Date: Sun, 19 Mar 2006 12:03:55 +0100 Subject: turing off selinux makes gnome 60% faster? In-Reply-To: <441D3896.6000205@feuerpokemon.de> References: <441D3896.6000205@feuerpokemon.de> Message-ID: <441D3A9B.4070604@feuerpokemon.de> dragoran wrote: > according to this review: > http://distrocenter.linux.com/distrocenter/06/03/08/2321254.shtml?tid=107 > "FC5 runs on a 2.6.15 kernel and uses a branded version of GNOME 2.14 > as its default desktop. Although GNOME 2.14 is roughly twice as fast > as earlier versions when installed in other distributions, little of > this acceleration is visible in FC5. A large part of this relative > slowness is due to the default enabling of SELinux -- turn it off, and > GNOME is as much as 60% faster." > > turing off selinux makes gnome 60% faster... > can this be true? > how does selinux affects gnome perfomance? > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > nm... old review used a debug enabled kernel From sds at tycho.nsa.gov Mon Mar 20 13:49:41 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 20 Mar 2006 08:49:41 -0500 Subject: turing off selinux makes gnome 60% faster? In-Reply-To: <441D3A9B.4070604@feuerpokemon.de> References: <441D3896.6000205@feuerpokemon.de> <441D3A9B.4070604@feuerpokemon.de> Message-ID: <1142862581.16487.11.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2006-03-19 at 12:03 +0100, dragoran wrote: > dragoran wrote: > > > according to this review: > > http://distrocenter.linux.com/distrocenter/06/03/08/2321254.shtml?tid=107 > > "FC5 runs on a 2.6.15 kernel and uses a branded version of GNOME 2.14 > > as its default desktop. Although GNOME 2.14 is roughly twice as fast > > as earlier versions when installed in other distributions, little of > > this acceleration is visible in FC5. A large part of this relative > > slowness is due to the default enabling of SELinux -- turn it off, and > > GNOME is as much as 60% faster." > > > > turing off selinux makes gnome 60% faster... > > can this be true? > > how does selinux affects gnome perfomance? > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > nm... > old review used a debug enabled kernel Yes, saw that review and asked its author for more detail, but he had already scrubbed the test machine for another review. Even with a debug-enabled kernel, I don't see any reason why there would be such an overhead from SELinux. One possible explanation might be that some background process was hitting an AVC denial due to yet another missing permission in the policy, thereby putting load on the audit system and flooding audit.log, which would slow down the system. -- Stephen Smalley National Security Agency From ejtr at layer3.co.uk Mon Mar 20 16:57:28 2006 From: ejtr at layer3.co.uk (Ted Rule) Date: Mon, 20 Mar 2006 16:57:28 +0000 Subject: The Silence of the Anacrons In-Reply-To: <4419ACE7.5080407@redhat.com> References: <1142423317.6433.32.camel@topaz.bugfinder.co.uk> <44181BD7.5080901@redhat.com> <1142437468.11026.27.camel@topaz.bugfinder.co.uk> <4419ACE7.5080407@redhat.com> Message-ID: <1142873849.7745.40.camel@topaz.bugfinder.co.uk> Having run SELinux in enableaudit mode, I see this: Mar 20 09:37:48 topaz kernel: audit(1142847445.519:9803): avc: denied { append } for pid=5507 comm="sendmail" name="fileVPVqYv" dev=hda10 ino=21 scontext=root:system_r:system_mail_t tcontext=root:object_r:system_crond_tmp_t tclass=file A partial workround is thus to add this to policy: # tail domains/misc/localpolicy.te ... allow system_mail_t { system_crond_tmp_t }:file { append }; # Since sendmail has no legitimate reason to write to a system_crond_tmp_t file, the original SELinux policy is "correct", and this is only a workround. After burrowing round the anacron source, I found that the problem arises because of the "dual-use" of a file-descriptor. anacron creates a temporary file, opens a file-descriptor read/write, unlinks the temporary filename, and then passes the FD as stdout/stderr to Job's it runs. Once the Jobs are complete, it passes the FD as stdin to sendmail. The problem appears to be that SELinux complains when sendmail tries to use an inherited FD with write-permissions to a system_crond_tmp_t file. Because the filename is unlinked after the file is opened, simply closing the FD and re-opening the temporary file read-only is not an option - or at least not a completely trivial one. As a patch, therefore, I've tweaked anacron to open the temporary file twice - once write-only and once read-only - before unlinking the filename. The read-only FD is redirected to stdin, the write-only FD is closed, and stdout/stderr redirected to /dev/null before exec-ing sendmail. This now added to Bugzilla as #185973 with an associated patch detailed therein. On Thu, 2006-03-16 at 13:22 -0500, Daniel J Walsh wrote: > Ted Rule wrote: > > The host is FC4 rather than FC5testN > > > > In order to avoid having to run in permissive overnight or completely > > reload the policy at the moment, I've run the following test: > > > > Create new directory /etc/anacron.daily and a corresponding entry > > in /etc/anacrontab. Create /etc/anacron.daily/0anacron and a test > > job /etc/anacron.daily/mailcheck. ( See below ) > > > > Run in enforcing by restarting anacron service with > > > > sudo service anacron start > > > > Wait 5 mins for Job to run, and note that the resultant Email is > > empty-bodied as with /etc/cron.daily > > > > Check anacron stopped. > > > > Delete the timestamp file /var/spool/anacron/anacron.daily > > > > Goto permissive with > > > > sudo setenforce 0 > > > > Wait 5 mins for Job to run, and note that the resultant Email is > > properly formed with Subject and body as expected. > > > > Go back to enforcing. > > > > This all seems to confirm to me that SELinux policy is somehow blanking > > the body and subject. The only denial messages I see during in > > permissive state are these: > > > > Mar 15 15:12:53 topaz sudo: ejtr : TTY=pts/1 ; PWD=/home/ejtr ; > > USER=root ; COMMAND=/sbin/service anacron start > > Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6922): avc: denied > > { read write } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 > > scontext=root:system_r:system_crond_t > > tcontext=user_u:object_r:user_devpts_t tclass=chr_file > > Mar 15 15:12:54 topaz kernel: audit(1142435574.018:6923): avc: denied > > { use } for pid=12151 comm="anacron" name="1" dev=devpts ino=3 > > scontext=root:system_r:system_crond_t tcontext=user_u:user_r:user_t > > tclass=fd > > > > which I think corresponds to the anacron processes being unable to write > > to the user_* FD's belonging to the shell which was used to invoke "sudo > > service". Since the AVC's are related to a user_* domain, I assume they > > are unrelated to the problem itself, which I imagine depends upon the > > interaction of the initrc_t, crond_t, and system_crond_t domains. > > > > I'll try and perform a similar test with an enableaudit policy as soon > > as I can. Obviously, the log may take a bit of weeding! > > > > > > ============================== > > $ cat /etc/anacrontab > > # /etc/anacrontab: configuration file for anacron > > > > # See anacron(8) and anacrontab(5) for details. > > > > SHELL=/bin/sh > > PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin > > MAILTO=root > > > > 1 5 anacron.daily run-parts /etc/anacron.daily > > 1 65 cron.daily run-parts /etc/cron.daily > > 7 70 cron.weekly run-parts /etc/cron.weekly > > 30 75 cron.monthly run-parts /etc/cron.monthly > > $ > > > > $ cat /etc/anacron.daily/0anacron > > #!/bin/sh > > # > > # anacron's cron script > > # > > # This script updates anacron time stamps. It is called through > > run-parts > > # either by anacron itself or by cron. > > # > > # The script is called "0anacron" to assure that it will be executed > > # _before_ all other scripts. > > > > anacron -u anacron.daily > > > > $ cat /etc/anacron.daily/mailcheck > > #!/bin/sh > > > > echo "Testing Anacron Mail system" > > > > cat /etc/resolv.conf > > > > $ > > > Please enter a bugzilla so we don't loose this. > > > > > > On Wed, 2006-03-15 at 08:51 -0500, Daniel J Walsh wrote: > > > >> Ted Rule wrote: > >> > >>> Something that's niggled me for a while are the empty Email messages > >>> generated by Anacron. > >>> > >>> This is on FC4 / selinux-policy-strict-1.27.1-2.22 > >>> > >>> When the machine is left powered overnight, the normal /etc/cron.daily > >>> processes - including logwatch and logrotate - run perfectly happily and > >>> generate appropriate Emails. > >>> > >>> By default, logrotate doesn't result in an Email, but for reasons > >>> unrelated to SELinux I have it set to run in debug mode, so my instance > >>> does. The Email from logrotate is effectively 'sent' by /etc/cron.daily > >>> as it wrappers all the output from its child jobs. > >>> > >>> In contrast, logwatch sends its own Email independent of Cron's sendmail > >>> child process. > >>> > >>> When the machine is depowered overnight and repowered in the morning, > >>> Anacron proceeds to run the various /etc/cron.daily scripts. With > >>> SELinux enforcing, logwatch runs normally, and generates its normal > >>> Email log summary. > >>> > >>> However, logrotate's output is never seen, even though it can be seen > >>> from the various timestamps and filenames that logrotate has correctly > >>> run and suitably rotated all the logs. > >>> > >>> The overall cron.daily Job launched by Anacron results in an empty > >>> Email, with no body and more particularly no Subject. The mail From > >>> address is set to "Anacron ". > >>> > >>> Burrowing around the Anacron source it is apparent that under normal > >>> circumstances it would give the Email a subject of > >>> > >>> "Anacron job cron.daily" > >>> > >>> Given the behaviour I see, I think the problem is somehow related to > >>> the /etc/cron.daily/* processes not having rights to write to the file > >>> descriptor which is the input to Cron's overall sendmail process. > >>> > >>> I've had a look through the SELinux policy to see if I can spot the > >>> difference between the permissions of Jobs launched by Cron and Anacron, > >>> and I'm afraid I can't see where the problem lies; since jobs launched > >>> by either method appear to run as system_crond_t, the difference in > >>> behaviour eludes me. > >>> > >>> Can anyone else offer any insight into the problem? > >>> > >>> Thanks, > >>> > >>> > >>> > >>> > >>> > >> Is this on FC5? If yes, are you seeing any AVC messages? If not could > >> you attempt to enable audit > >> > >> semodule -b /usr/share/selinux/targeted/enableaudit.pp > >> > >> Create the error. > >> > >> Grab the AVC Messages > >> > >> semodule -b /usr/share/selinux/targeted/base.pp > >> > >> to turn off auditing again. > >> > >> > >> Of course verifying this works with setenforce 0 would also help to make > >> sure it is SELinux causing the problem. > >> > >> > > > > > -- Ted Rule Director, Layer3 Systems Ltd E: ejtr at layer3.co.uk W: http://www.layer3.co.uk/ T: 020-8769-4484 From dwalsh at redhat.com Mon Mar 20 19:25:14 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Mon, 20 Mar 2006 14:25:14 -0500 Subject: My blog entry about New Features of SELinux in FC5. Message-ID: <441F019A.6090606@redhat.com> http://danwalsh.livejournal.com/2213.html Lots more information is also available on http://fedoraproject.org/wiki/SELinux Dan From gajownik at fedora.pl Tue Mar 21 21:01:51 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Tue, 21 Mar 2006 22:01:51 +0100 Subject: logwatch does not show disk usage of partitions mounted in /mnt Message-ID: <442069BF.6030902@fedora.pl> Hi! In mails from logwatch there is something like this: --------------------- Disk Space Begin ------------------------ Filesystem Size Used Avail Use% Mounted on df: `/mnt/FreeDOS': Access denied I found this avc message: Mar 21 17:14:05 X kernel: audit(1142957645.904:32): avc: denied { search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir OS: FC5 selinux-policy-targeted: 2.2.23-15 How can I fix it? Regards, Dawid -- ^_* From gajownik at fedora.pl Tue Mar 21 21:45:50 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Tue, 21 Mar 2006 22:45:50 +0100 Subject: turing off selinux makes gnome 60% faster? In-Reply-To: <441D3896.6000205@feuerpokemon.de> References: <441D3896.6000205@feuerpokemon.de> Message-ID: <4420740E.6060607@fedora.pl> Dnia 03/19/2006 11:59 AM, U?ytkownik dragoran napisa?: > how does selinux affects gnome perfomance? I've read this mail ? http://www.redhat.com/archives/fedora-devel-list/2006-March/msg00580.html and I also wanted to ask how SELinux actually affects performance :) It's really strange that no one have made new benchmarks. This should be quite easy for someone who did it in the past (or am I wrong?). _Correct_ comparison between SELinux and AppArmor performance would be also nice. IMHO actuall situation really hurts SELinux from the marketing point of view (I mean outdated information). Regards, Dawid -- ^_* From lists at ebourne.me.uk Wed Mar 22 11:52:34 2006 From: lists at ebourne.me.uk (Martin Ebourne) Date: Wed, 22 Mar 2006 11:52:34 +0000 Subject: error in 'make load' Message-ID: <1143028354.6234.6.camel@avenin.ebourne.me.uk> Stephen Smalley wrote: > On Mon, 2006-02-20 at 07:44 -0700, gf wrote: > > Hi, > > I am trying to update the httpd policy in selinux to allow access to port 8443. > > I thought that I could add the line > > portcon tcp 8443 system_u:object_r:http_port_t > > to the file > > /etc/selinux/targeted/src/policy/net_contents > > and recompile. > > > > My first step was to download the sources: > > selinux-policy-targeted-sources-1.17.30-2.110.rpm > > and install. > > > > To check whether or not everthing was working, I tried the following > > without altering any files: > > > > [$ /etc/selinux/targeted/src/policy]:make load > > mkdir -p /etc/selinux/targeted/policy > > /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 policy.conf > > /usr/bin/checkpolicy: loading policy configuration from policy.conf > > tmp/program_used_flags.te:2:ERROR 'syntax error' at token > > '/etc/selinux/targeted/src/policy/domains/program' on line 1164: > > /etc/selinux/targeted/src/policy/domains/program > > #line 1 "tmp/program_used_flags.te" > > /usr/bin/checkpolicy: error(s) encountered while parsing configuration > > make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 > > Sounds like a bug in the policy Makefile in the generation of the > policy.conf file, as that string > ('/etc/selinux/targeted/src/policy/domains/program') shouldn't appear in > it. Provide more context please, e.g. the lines around line 1164 of the > policy.conf file. I've just come across this error myself. I've got two updated FC4 machines here both doing the same thing. Turns out it's a 'cd' in the Makefile that is echoing the new directory and getting caught up in the destination file. The odd thing is that my shell setup has never had cd echoing the destination (it would annoy me - if I've just cd'd, I know where to!), so this must be something from Fedora. Anyhow, the attached patch fixes it for me. Any chance this can make it upstream? [Stephen, thanks for the clue that let me to find this!] Cheers, Martin. -------------- next part -------------- A non-text attachment was scrubbed... Name: Makefile.diff Type: text/x-patch Size: 722 bytes Desc: URL: From sds at tycho.nsa.gov Wed Mar 22 12:58:35 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 22 Mar 2006 07:58:35 -0500 Subject: error in 'make load' In-Reply-To: <1143028354.6234.6.camel@avenin.ebourne.me.uk> References: <1143028354.6234.6.camel@avenin.ebourne.me.uk> Message-ID: <1143032315.28120.143.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-22 at 11:52 +0000, Martin Ebourne wrote: > Stephen Smalley wrote: > > On Mon, 2006-02-20 at 07:44 -0700, gf wrote: > > > Hi, > > > I am trying to update the httpd policy in selinux to allow access to > port 8443. > > > I thought that I could add the line > > > portcon tcp 8443 system_u:object_r:http_port_t > > > to the file > > > /etc/selinux/targeted/src/policy/net_contents > > > and recompile. > > > > > > My first step was to download the sources: > > > selinux-policy-targeted-sources-1.17.30-2.110.rpm > > > and install. > > > > > > To check whether or not everthing was working, I tried the following > > > without altering any files: > > > > > > [$ /etc/selinux/targeted/src/policy]:make load > > > mkdir -p /etc/selinux/targeted/policy > > > /usr/bin/checkpolicy -o /etc/selinux/targeted/policy/policy.18 > policy.conf > > > /usr/bin/checkpolicy: loading policy configuration from policy.conf > > > tmp/program_used_flags.te:2:ERROR 'syntax error' at token > > > '/etc/selinux/targeted/src/policy/domains/program' on line 1164: > > > /etc/selinux/targeted/src/policy/domains/program > > > #line 1 "tmp/program_used_flags.te" > > > /usr/bin/checkpolicy: error(s) encountered while parsing > configuration > > > make: *** [/etc/selinux/targeted/policy/policy.18] Error 1 > > > > Sounds like a bug in the policy Makefile in the generation of the > > policy.conf file, as that string > > ('/etc/selinux/targeted/src/policy/domains/program') shouldn't appear > in > > it. Provide more context please, e.g. the lines around line 1164 of > the > > policy.conf file. > > I've just come across this error myself. I've got two updated FC4 > machines here both doing the same thing. > > Turns out it's a 'cd' in the Makefile that is echoing the new directory > and getting caught up in the destination file. The odd thing is that my > shell setup has never had cd echoing the destination (it would annoy me > - if I've just cd'd, I know where to!), so this must be something from > Fedora. > > Anyhow, the attached patch fixes it for me. Any chance this can make it > upstream? > > [Stephen, thanks for the clue that let me to find this!] Example policy is no longer maintained upstream (obsoleted by the reference policy, which is the basis for policy in FC5). But you could file a bugzilla against the FC4 policy to get it fixed there. -- Stephen Smalley National Security Agency From gyromagnetic at gmail.com Wed Mar 22 13:02:37 2006 From: gyromagnetic at gmail.com (gf) Date: Wed, 22 Mar 2006 06:02:37 -0700 Subject: error in 'make load' In-Reply-To: <1143028354.6234.6.camel@avenin.ebourne.me.uk> References: <1143028354.6234.6.camel@avenin.ebourne.me.uk> Message-ID: On 3/22/06, Martin Ebourne wrote: > Stephen Smalley wrote: > > I've just come across this error myself. I've got two updated FC4 > machines here both doing the same thing. > > Turns out it's a 'cd' in the Makefile that is echoing the new directory > and getting caught up in the destination file. The odd thing is that my > shell setup has never had cd echoing the destination (it would annoy me > - if I've just cd'd, I know where to!), so this must be something from > Fedora. > > Anyhow, the attached patch fixes it for me. Any chance this can make it > upstream? > > [Stephen, thanks for the clue that let me to find this!] > > Cheers, > > Martin. > Hi, With Stephen's help, I reached the same conclusion. I should have cc'ed my latter emails to the list. I think that the problem arises due to the presence of a non-blank CDPATH. It appears that POSIX.2 says that if a nonempty directory from CDPATH is used to find the directory to change to, the new directory name is echoed to stdout, regardless of whether or not the shell is interactive. Aside from the patch that Martin provided, 'unsetting' CDPATH cures the problem for me. - g From dwalsh at redhat.com Wed Mar 22 15:11:38 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 22 Mar 2006 10:11:38 -0500 Subject: logwatch does not show disk usage of partitions mounted in /mnt In-Reply-To: <442069BF.6030902@fedora.pl> References: <442069BF.6030902@fedora.pl> Message-ID: <4421692A.1080205@redhat.com> Dawid Gajownik wrote: > Hi! > > In mails from logwatch there is something like this: > > --------------------- Disk Space Begin ------------------------ > > Filesystem Size Used Avail Use% Mounted on > df: `/mnt/FreeDOS': Access denied > > I found this avc message: > > Mar 21 17:14:05 X kernel: audit(1142957645.904:32): avc: denied { > search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > > OS: FC5 > selinux-policy-targeted: 2.2.23-15 > > How can I fix it? First make sure this is all the access that it needs by running logwatch with setenforce 0. Then send us the AVC messages, so we can update policy. You can also install a loadable module to allow this access by executing grep logwatch /var/log/audit/audit.log | audit2allow -M logwatch semodule -i logwatch.pp > > Regards, > Dawid > From fenn at stanford.edu Wed Mar 22 19:43:04 2006 From: fenn at stanford.edu (Tim Fenn) Date: Wed, 22 Mar 2006 11:43:04 -0800 Subject: FC5 dbus-deamon name_connect denied Message-ID: <20060322194253.GB24794@stanford.edu> After upgrading from FC4 to FC5, everything seems to be working well, except for the dbus-daemon. It hogs CPU and continuously spits out the following, unless messagebus is stopped: audit(1143051102.334:1219773): avc: denied { name_connect } for pid=24150 comm="dbus-daemon" dest=111 scontext=user_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket audit(1143051102.334:1219773): arch=40000003 syscall=102 success=no exit=-13 a0=3 a1=bfa7fbec a2=da4ff4 a3=0 items=0 pid=24150 auid=1567 uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 fsgid=81 comm="dbus-daemon" exe="/bin/dbus-daemon" audit(1143051102.334:1219773): saddr=0200006F7F00000168C56709C0916700 audit(1143051102.334:1219773): nargs=3 a0=c a1=bfa7fcfc a2=10 I'm sure I missed something simple (as usual). Any hints? If it helps, I'm using: selinux-policy-2.2.23-15 selinux-policy-targeted-2.2.23-15 Thanks for any pointers, Tim From dwalsh at redhat.com Wed Mar 22 20:36:49 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 22 Mar 2006 15:36:49 -0500 Subject: FC5 dbus-deamon name_connect denied In-Reply-To: <20060322194253.GB24794@stanford.edu> References: <20060322194253.GB24794@stanford.edu> Message-ID: <4421B561.3070401@redhat.com> Tim Fenn wrote: > After upgrading from FC4 to FC5, everything seems to be working well, > except for the dbus-daemon. It hogs CPU and continuously spits out > the following, unless messagebus is stopped: > > audit(1143051102.334:1219773): avc: denied { name_connect } for > pid=24150 comm="dbus-daemon" dest=111 > scontext=user_u:system_r:system_dbusd_t:s0 > tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket > > audit(1143051102.334:1219773): arch=40000003 syscall=102 success=no > exit=-13 a0=3 a1=bfa7fbec a2=da4ff4 a3=0 items=0 pid=24150 auid=1567 > uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 fsgid=81 > comm="dbus-daemon" exe="/bin/dbus-daemon" > > audit(1143051102.334:1219773): saddr=0200006F7F00000168C56709C0916700 > audit(1143051102.334:1219773): nargs=3 a0=c a1=bfa7fcfc a2=10 > > I'm sure I missed something simple (as usual). Any hints? > > If it helps, I'm using: > > selinux-policy-2.2.23-15 > selinux-policy-targeted-2.2.23-15 > > Thanks for any pointers, > Tim > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Are you running on an NIS machine? If yes is the allow_ypbind boolean turned on? getsebool allow_ypbind If not turn it on setsebool -P allow_ypbind=1 Dan From rhallyx at mindspring.com Wed Mar 22 19:00:18 2006 From: rhallyx at mindspring.com (Richard Hally) Date: Wed, 22 Mar 2006 14:00:18 -0500 Subject: postinstall error from selinux-policy-targeted Message-ID: <44219EC2.9070600@mindspring.com> todays rawhide update produced the following error: Updating : selinux-policy-targeted ##################### [ 57/119] /var/tmp/rpm-tmp.10515: line 10: /usr/sbin/fixfiles: No such file or directory It looks like the postinstall script has the wrong path for fixfiles. selinux-policy-targeted-2.2.24-1. From bobk at ocf.berkeley.edu Thu Mar 23 00:12:32 2006 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Wed, 22 Mar 2006 16:12:32 -0800 Subject: libsetrans 1.20 missing from updates-testing FC5 repo Message-ID: <1143072752.2301.4.camel@chaucer> libsetrans >= 0.1.20-1 seems to be missing from updates-testing repo in FC5. When I run yum update it complains about the missing dependency. It seems to be needed by libselinux-1.30-1.fc5. Bob -- Bob Kashani http://www.gnome.org/~bobk/ From fenn at stanford.edu Thu Mar 23 09:17:24 2006 From: fenn at stanford.edu (Tim Fenn) Date: Thu, 23 Mar 2006 01:17:24 -0800 Subject: FC5 dbus-deamon name_connect denied In-Reply-To: <4421B561.3070401@redhat.com> References: <20060322194253.GB24794@stanford.edu> <4421B561.3070401@redhat.com> Message-ID: <20060323091714.GA29328@stanford.edu> On Wed, Mar 22, 2006 at 03:36:49PM -0500, Daniel J Walsh wrote: > Tim Fenn wrote: > >After upgrading from FC4 to FC5, everything seems to be working well, > >except for the dbus-daemon. It hogs CPU and continuously spits out > >the following, unless messagebus is stopped: > > > >audit(1143051102.334:1219773): avc: denied { name_connect } for > >pid=24150 comm="dbus-daemon" dest=111 > >scontext=user_u:system_r:system_dbusd_t:s0 > >tcontext=system_u:object_r:portmap_port_t:s0 tclass=tcp_socket > > > >audit(1143051102.334:1219773): arch=40000003 syscall=102 success=no > >exit=-13 a0=3 a1=bfa7fbec a2=da4ff4 a3=0 items=0 pid=24150 auid=1567 > >uid=81 gid=81 euid=81 suid=81 fsuid=81 egid=81 sgid=81 fsgid=81 > >comm="dbus-daemon" exe="/bin/dbus-daemon" > > > >audit(1143051102.334:1219773): saddr=0200006F7F00000168C56709C0916700 > >audit(1143051102.334:1219773): nargs=3 a0=c a1=bfa7fcfc a2=10 > > > >I'm sure I missed something simple (as usual). Any hints? > > > >If it helps, I'm using: > > > >selinux-policy-2.2.23-15 > >selinux-policy-targeted-2.2.23-15 > > > >Thanks for any pointers, > >Tim > > > Are you running on an NIS machine? If yes is the allow_ypbind boolean > turned on? > > getsebool allow_ypbind > > If not turn it on > > setsebool -P allow_ypbind=1 > Thanks - that fixed it. -Tim From gajownik at fedora.pl Thu Mar 23 15:10:25 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 23 Mar 2006 16:10:25 +0100 Subject: logwatch does not show disk usage of partitions mounted in /mnt In-Reply-To: <4421692A.1080205@redhat.com> References: <442069BF.6030902@fedora.pl> <4421692A.1080205@redhat.com> Message-ID: <4422BA61.3020605@fedora.pl> Dnia 03/22/2006 04:15 PM, U?ytkownik Daniel J Walsh napisa?: > First make sure this is all the access that it needs by running logwatch > with setenforce 0. > > Then send us the AVC messages, so we can update policy. I run today my system in permissive mode and logwatch showed disk usage of all partitions mounted in /mnt. Here are AVC messages: [root at X ~]# grep -i logwatch /var/log/messages Mar 21 17:14:05 X kernel: audit(1142957645.904:32): avc: denied { search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 21 17:14:05 X kernel: audit(1142957645.904:33): avc: denied { search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 21 17:14:05 X kernel: audit(1142957645.904:34): avc: denied { search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 21 17:14:05 X kernel: audit(1142957645.904:35): avc: denied { search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 21 17:14:05 X kernel: audit(1142957645.904:36): avc: denied { search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 21 17:14:05 X kernel: audit(1142957645.908:37): avc: denied { search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 22 12:31:53 X kernel: audit(1143027113.272:34): avc: denied { search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 22 12:31:53 X kernel: audit(1143027113.276:35): avc: denied { search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 22 12:31:53 X kernel: audit(1143027113.276:36): avc: denied { search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 22 12:31:53 X kernel: audit(1143027113.276:37): avc: denied { search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 22 12:31:53 X kernel: audit(1143027113.276:38): avc: denied { search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 22 12:31:53 X kernel: audit(1143027113.276:39): avc: denied { search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir Mar 23 12:16:48 X kernel: audit(1143112608.114:7): avc: denied { search } for pid=3333 comm="df" name="mnt" dev=hda5 ino=809601 scontext=system_u:system_r:logwatch_t:s0 tcontext=system_u:object_r:mnt_t:s0 tclass=dir [root at X ~]# (Yes, I don't have auditd.) > You can also install a loadable module to allow this access by executing > > grep logwatch /var/log/audit/audit.log | audit2allow -M logwatch > semodule -i logwatch.pp I know about audit2allow, but this program sometimes allows to much. I wanted to ask about this issue developers of SELinux policy :) Thanks, Dawid -- ^_* From dwalsh at redhat.com Thu Mar 23 15:57:49 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 23 Mar 2006 10:57:49 -0500 Subject: postinstall error from selinux-policy-targeted In-Reply-To: <44219EC2.9070600@mindspring.com> References: <44219EC2.9070600@mindspring.com> Message-ID: <4422C57D.8070309@redhat.com> Richard Hally wrote: > todays rawhide update produced the following error: > Updating : selinux-policy-targeted ##################### [ 57/119] > /var/tmp/rpm-tmp.10515: line 10: /usr/sbin/fixfiles: No such file or > directory > > It looks like the postinstall script has the wrong path for fixfiles. > selinux-policy-targeted-2.2.24-1. > Fixed in 25 > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Thu Mar 23 16:08:14 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 23 Mar 2006 11:08:14 -0500 Subject: logwatch does not show disk usage of partitions mounted in /mnt In-Reply-To: <4422BA61.3020605@fedora.pl> References: <442069BF.6030902@fedora.pl> <4421692A.1080205@redhat.com> <4422BA61.3020605@fedora.pl> Message-ID: <4422C7EE.3000006@redhat.com> Dawid Gajownik wrote: > Dnia 03/22/2006 04:15 PM, U?ytkownik Daniel J Walsh napisa?: > >> First make sure this is all the access that it needs by running >> logwatch with setenforce 0. >> >> Then send us the AVC messages, so we can update policy. > > I run today my system in permissive mode and logwatch showed disk > usage of all partitions mounted in /mnt. Here are AVC messages: > > [root at X ~]# grep -i logwatch /var/log/messages > Mar 21 17:14:05 X kernel: audit(1142957645.904:32): avc: denied { > search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 21 17:14:05 X kernel: audit(1142957645.904:33): avc: denied { > search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 21 17:14:05 X kernel: audit(1142957645.904:34): avc: denied { > search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 21 17:14:05 X kernel: audit(1142957645.904:35): avc: denied { > search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 21 17:14:05 X kernel: audit(1142957645.904:36): avc: denied { > search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 21 17:14:05 X kernel: audit(1142957645.908:37): avc: denied { > search } for pid=2588 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 22 12:31:53 X kernel: audit(1143027113.272:34): avc: denied { > search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 22 12:31:53 X kernel: audit(1143027113.276:35): avc: denied { > search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 22 12:31:53 X kernel: audit(1143027113.276:36): avc: denied { > search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 22 12:31:53 X kernel: audit(1143027113.276:37): avc: denied { > search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 22 12:31:53 X kernel: audit(1143027113.276:38): avc: denied { > search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 22 12:31:53 X kernel: audit(1143027113.276:39): avc: denied { > search } for pid=3307 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > Mar 23 12:16:48 X kernel: audit(1143112608.114:7): avc: denied { > search } for pid=3333 comm="df" name="mnt" dev=hda5 ino=809601 > scontext=system_u:system_r:logwatch_t:s0 > tcontext=system_u:object_r:mnt_t:s0 tclass=dir > [root at X ~]# > > (Yes, I don't have auditd.) > >> You can also install a loadable module to allow this access by executing >> >> grep logwatch /var/log/audit/audit.log | audit2allow -M logwatch >> semodule -i logwatch.pp > > I know about audit2allow, but this program sometimes allows to much. I > wanted to ask about this issue developers of SELinux policy :) > Well I am a developer of SELinux policy. The policy I put out yesterday will dontaudit this, but now I am thinking it should be allowed. > Thanks, > Dawid > From gajownik at fedora.pl Thu Mar 23 16:33:44 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 23 Mar 2006 17:33:44 +0100 Subject: logwatch does not show disk usage of partitions mounted in /mnt In-Reply-To: <4422C7EE.3000006@redhat.com> References: <442069BF.6030902@fedora.pl> <4421692A.1080205@redhat.com> <4422BA61.3020605@fedora.pl> <4422C7EE.3000006@redhat.com> Message-ID: <4422CDE8.6000501@fedora.pl> Dnia 03/23/2006 05:11 PM, U?ytkownik Daniel J Walsh napisa?: > Well I am a developer of SELinux policy. Yes, I know :) BTW Thanks for the nice "SELinux for Dummies" articles. > The policy I put out yesterday will dontaudit this, but now I am > thinking it should be allowed. Thanks, I'll check the new policy. -- ^_* From bobk at ocf.berkeley.edu Fri Mar 24 19:58:52 2006 From: bobk at ocf.berkeley.edu (Bob Kashani) Date: Fri, 24 Mar 2006 11:58:52 -0800 Subject: FC5 hpiod AVC's Message-ID: <1143230332.2338.6.camel@chaucer> This is on a fresh install of FC5 with all the latest updates as of March 24th. libsepol-1.12.1-1.fc5 selinux-policy-2.2.25-2.fc5 selinux-policy-targeted-2.2.25-2.fc5 libsetrans-0.1.20-1.fc5 libselinux-python-1.30-1.fc5 libsemanage-1.6-1.fc5 libselinux-1.30-1.fc5 hplip-0.9.9-5.1 hpijs-0.9.9-5.1 [medieval at chaucer ~]$ audit2allow -d allow hplip_t usb_device_t:chr_file { read write }; Mar 24 11:41:49 chaucer kernel: audit(1143229305.812:2): avc: denied { read write } for pid=1733 comm="hpiod" name="001" \dev=tmpfs ino=4260 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.812:3): avc: denied { read } for pid=1733 comm="hpiod" name="001" dev=tm\pfs ino=4260 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.812:4): avc: denied { read write } for pid=1733 comm="hpiod" name="001" \dev=tmpfs ino=4208 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.812:5): avc: denied { read } for pid=1733 comm="hpiod" name="001" dev=tm\pfs ino=4208 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.812:6): avc: denied { read write } for pid=1733 comm="hpiod" name="001" \dev=tmpfs ino=4158 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.812:7): avc: denied { read } for pid=1733 comm="hpiod" name="001" dev=tm\pfs ino=4158 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.812:8): avc: denied { read write } for pid=1733 comm="hpiod" name="001" \dev=tmpfs ino=4108 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.812:9): avc: denied { read } for pid=1733 comm="hpiod" name="001" dev=tm\pfs ino=4108 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: ppdev: user-space parallel port driver Mar 24 11:41:49 chaucer kernel: audit(1143229305.992:10): avc: denied { read write } for pid=1745 comm="hpiod" name="001"\ dev=tmpfs ino=4260 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.992:11): avc: denied { read } for pid=1745 comm="hpiod" name="001" dev=t\mpfs ino=4260 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.992:12): avc: denied { read write } for pid=1745 comm="hpiod" name="001"\ dev=tmpfs ino=4208 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.992:13): avc: denied { read } for pid=1745 comm="hpiod" name="001" dev=t\mpfs ino=4208 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.992:14): avc: denied { read write } for pid=1745 comm="hpiod" name="001"\ dev=tmpfs ino=4158 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.992:15): avc: denied { read } for pid=1745 comm="hpiod" name="001" dev=t\mpfs ino=4158 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.992:16): avc: denied { read write } for pid=1745 comm="hpiod" name="001"\ dev=tmpfs ino=4108 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Mar 24 11:41:49 chaucer kernel: audit(1143229305.992:17): avc: denied { read } for pid=1745 comm="hpiod" name="001" dev=t\mpfs ino=4108 scontext=system_u:system_r:hplip_t:s0 tcontext=system_u:object_r:usb_device_t:s0 tclass=chr_file Bob -- Bob Kashani http://www.gnome.org/~bobk/ From mike at flyn.org Sat Mar 25 02:19:56 2006 From: mike at flyn.org (W. Michael Petullo) Date: Fri, 24 Mar 2006 20:19:56 -0600 Subject: M4 processing for SELinux module Message-ID: <20060325021956.GA15721@imp.flyn.org> I've found some good documentation on building SELinux modules at http://sepolicy-server.sourceforge.net/index.php?page=module-overview. However, this article states, "Note that the syslog.te file must already be preprocessed by m4 if it contains macros." I can't find any clear documentation that describes how to perform this step. How does one process a policy source file using m4 and what package provides the required macro definitions (i.e.: domain_auto_trans?) -- Mike :wq From rhallyx at mindspring.com Sat Mar 25 17:34:45 2006 From: rhallyx at mindspring.com (Richard Hally) Date: Sat, 25 Mar 2006 12:34:45 -0500 Subject: strict module linking Message-ID: <44257F35.7040602@mindspring.com> From yum update today (3/25/06). Just in case someone missed it. " Updating : selinux-policy-strict ####################### [20/47] libsepol.scope_copy_callback: vpnc: Duplicate declaration in module: type/attribute vpnc_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! " [root at LinuxNew2 ~]# rpm -q selinux-policy-strict selinux-policy-strict-2.2.26-1 From bench at silentmedia.com Sat Mar 25 20:10:37 2006 From: bench at silentmedia.com (Ben) Date: Sat, 25 Mar 2006 12:10:37 -0800 Subject: adduser rights on FC5 Message-ID: <03FDF1E1-ED99-4DB3-A513-C721528B95BC@silentmedia.com> I have a fresh FC5 install that I tried to add the heatbeat package to, and saw this: Mar 25 12:04:28 johnny kernel: audit(1143317068.339:75): avc: denied { read write } for pid=19283 comm="useradd" name="lastlog" dev=dm-0 ino=880549 scontext=root:system_r:useradd_t:s0-s0:c0.c255 tcontext=system_u:object_r:var_log_t:s0 tclass=file Mar 25 12:05:28 johnny yum: Installed: heartbeat.x86_64 2.0.3-9.fc5 I'm running the most recent targeted config, 2.2.23-15. Should I be worried that heartbeat didn't install properly? From paul at city-fan.org Sun Mar 26 08:48:30 2006 From: paul at city-fan.org (Paul Howarth) Date: Sun, 26 Mar 2006 09:48:30 +0100 Subject: context mount options in FC5 Message-ID: <1143362910.4975.103.camel@laurel.intra.city-fan.org> The "context" and "fscontext" mount options no longer seem to be supported by mount in FC5: # mount -r -o loop,fscontext=system_u:object_r:public_content_t /srv/softlib/fedora/bordeaux/FC-5-i386-DVD.iso /srv/softlib/fedora/bordeaux/dvd mount: wrong fs type, bad option, bad superblock on /dev/loop1, missing codepage or other error In some cases useful info is found in syslog - try dmesg | tail or so The same command fails in the same way with "fscontext" changed to "context", but works if neither of those options is present. This leaves me with the mounted DVD image having a context of iso9660_t, which is reasonable but not what I want for serving out a local yum repository. So how can I get ISO images mounted with public_content_t in FC5? Or am I going to have to create a policy module to allow httpd, ftpd, samba etc. to read iso9660_t? Paul. From sds at tycho.nsa.gov Mon Mar 27 13:47:45 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 27 Mar 2006 08:47:45 -0500 Subject: context mount options in FC5 In-Reply-To: <1143362910.4975.103.camel@laurel.intra.city-fan.org> References: <1143362910.4975.103.camel@laurel.intra.city-fan.org> Message-ID: <1143467265.22696.11.camel@moss-spartans.epoch.ncsc.mil> On Sun, 2006-03-26 at 09:48 +0100, Paul Howarth wrote: > The "context" and "fscontext" mount options no longer seem to be > supported by mount in FC5: > > # mount -r -o > loop,fscontext=system_u:object_r:public_content_t /srv/softlib/fedora/bordeaux/FC-5-i386-DVD.iso /srv/softlib/fedora/bordeaux/dvd > mount: wrong fs type, bad option, bad superblock on /dev/loop1, > missing codepage or other error > In some cases useful info is found in syslog - try > dmesg | tail or so > > The same command fails in the same way with "fscontext" changed to > "context", but works if neither of those options is present. This leaves > me with the mounted DVD image having a context of iso9660_t, which is > reasonable but not what I want for serving out a local yum repository. > > So how can I get ISO images mounted with public_content_t in FC5? > > Or am I going to have to create a policy module to allow httpd, ftpd, > samba etc. to read iso9660_t? Error message that I get in /var/log/messages is SELinux: security_context_to_sid(system_u:object_r:public_content_t) failed ... errno=-22 (EINVAL). But if I add a ':s0' suffix to the context, it works. So IIUC the problem here is that mount is directly passing the user-supplied context to the kernel without interacting with libselinux to translate it (via selinux_trans_to_raw_context). Needs to be patched accordingly, and updated in FC5 as well as rawhide. -- Stephen Smalley National Security Agency From paul at city-fan.org Mon Mar 27 13:51:41 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 27 Mar 2006 14:51:41 +0100 Subject: context mount options in FC5 In-Reply-To: <1143467265.22696.11.camel@moss-spartans.epoch.ncsc.mil> References: <1143362910.4975.103.camel@laurel.intra.city-fan.org> <1143467265.22696.11.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4427EDED.4030001@city-fan.org> Stephen Smalley wrote: > On Sun, 2006-03-26 at 09:48 +0100, Paul Howarth wrote: >> The "context" and "fscontext" mount options no longer seem to be >> supported by mount in FC5: >> >> # mount -r -o >> loop,fscontext=system_u:object_r:public_content_t /srv/softlib/fedora/bordeaux/FC-5-i386-DVD.iso /srv/softlib/fedora/bordeaux/dvd >> mount: wrong fs type, bad option, bad superblock on /dev/loop1, >> missing codepage or other error >> In some cases useful info is found in syslog - try >> dmesg | tail or so >> >> The same command fails in the same way with "fscontext" changed to >> "context", but works if neither of those options is present. This leaves >> me with the mounted DVD image having a context of iso9660_t, which is >> reasonable but not what I want for serving out a local yum repository. >> >> So how can I get ISO images mounted with public_content_t in FC5? >> >> Or am I going to have to create a policy module to allow httpd, ftpd, >> samba etc. to read iso9660_t? > > Error message that I get in /var/log/messages is > SELinux: security_context_to_sid(system_u:object_r:public_content_t) > failed ... errno=-22 (EINVAL). > > But if I add a ':s0' suffix to the context, it works. So IIUC the > problem here is that mount is directly passing the user-supplied context > to the kernel without interacting with libselinux to translate it (via > selinux_trans_to_raw_context). Needs to be patched accordingly, and > updated in FC5 as well as rawhide. Thanks, that's fixed it. I assume it's safe to add the ":s0" to an fstab entry as that will pass through the libselinux translation transparently? Paul. From sds at tycho.nsa.gov Mon Mar 27 14:02:17 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 27 Mar 2006 09:02:17 -0500 Subject: context mount options in FC5 In-Reply-To: <4427EDED.4030001@city-fan.org> References: <1143362910.4975.103.camel@laurel.intra.city-fan.org> <1143467265.22696.11.camel@moss-spartans.epoch.ncsc.mil> <4427EDED.4030001@city-fan.org> Message-ID: <1143468137.22696.13.camel@moss-spartans.epoch.ncsc.mil> On Mon, 2006-03-27 at 14:51 +0100, Paul Howarth wrote: > Thanks, that's fixed it. I assume it's safe to add the ":s0" to an fstab > entry as that will pass through the libselinux translation transparently? Yes, if the user (or in this case, fstab file) specifies a MCS/MLS component in the raw format, then the translation library should leave it alone. But this does need to be fixed in mount, likely should be bugzilla'd. -- Stephen Smalley National Security Agency From paul at city-fan.org Mon Mar 27 14:12:28 2006 From: paul at city-fan.org (Paul Howarth) Date: Mon, 27 Mar 2006 15:12:28 +0100 Subject: context mount options in FC5 In-Reply-To: <1143468137.22696.13.camel@moss-spartans.epoch.ncsc.mil> References: <1143362910.4975.103.camel@laurel.intra.city-fan.org> <1143467265.22696.11.camel@moss-spartans.epoch.ncsc.mil> <4427EDED.4030001@city-fan.org> <1143468137.22696.13.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <4427F2CC.1040308@city-fan.org> Stephen Smalley wrote: > On Mon, 2006-03-27 at 14:51 +0100, Paul Howarth wrote: >> Thanks, that's fixed it. I assume it's safe to add the ":s0" to an fstab >> entry as that will pass through the libselinux translation transparently? > > Yes, if the user (or in this case, fstab file) specifies a MCS/MLS > component in the raw format, then the translation library should leave > it alone. But this does need to be fixed in mount, likely should be > bugzilla'd. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=186915 Paul From sds at tycho.nsa.gov Mon Mar 27 15:12:45 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Mon, 27 Mar 2006 10:12:45 -0500 Subject: M4 processing for SELinux module In-Reply-To: <20060325021956.GA15721@imp.flyn.org> References: <20060325021956.GA15721@imp.flyn.org> Message-ID: <1143472365.22696.63.camel@moss-spartans.epoch.ncsc.mil> On Fri, 2006-03-24 at 20:19 -0600, W. Michael Petullo wrote: > I've found some good documentation on building SELinux modules at > http://sepolicy-server.sourceforge.net/index.php?page=module-overview. > However, this article states, "Note that the syslog.te file must already > be preprocessed by m4 if it contains macros." I can't find any clear > documentation that describes how to perform this step. > > How does one process a policy source file using m4 and what package > provides the required macro definitions (i.e.: domain_auto_trans?) selinux-policy provides /usr/share/selinux/devel and /usr/share/doc/selinux-policy-x.y.z. There should be a Makefile and include tree under the devel directory that can be used to easily build policy modules. There is also a start at a policygentool, but I think the one that shipped in FC5 wasn't quite working. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Tue Mar 28 15:08:39 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 28 Mar 2006 10:08:39 -0500 Subject: adduser rights on FC5 In-Reply-To: <03FDF1E1-ED99-4DB3-A513-C721528B95BC@silentmedia.com> References: <03FDF1E1-ED99-4DB3-A513-C721528B95BC@silentmedia.com> Message-ID: <44295177.4080500@redhat.com> Ben wrote: > I have a fresh FC5 install that I tried to add the heatbeat package > to, and saw this: > > Mar 25 12:04:28 johnny kernel: audit(1143317068.339:75): avc: denied > { read write } for pid=19283 comm="useradd" name="lastlog" dev=dm-0 > ino=880549 scontext=root:system_r:useradd_t:s0-s0:c0.c255 > tcontext=system_u:object_r:var_log_t:s0 tclass=file > Mar 25 12:05:28 johnny yum: Installed: heartbeat.x86_64 2.0.3-9.fc5 > > I'm running the most recent targeted config, 2.2.23-15. Should I be > worried that heartbeat didn't install properly? > restorecon -v /var/log/lastlog Somehow this got the wrong context on install. > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list From dwalsh at redhat.com Tue Mar 28 15:28:23 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Tue, 28 Mar 2006 10:28:23 -0500 Subject: selinux-policy-targeted-2.2.26-1 policy was bad. In-Reply-To: <200603281337.22271.billcrawford1970@googlemail.com> References: <1143316951.4425a1d750bff@www.jouy.inra.fr> <1143321367.14370.3.camel@localhost.localdomain> <44280CE5.8010802@redhat.com> <200603281337.22271.billcrawford1970@googlemail.com> Message-ID: <44295617.2070405@redhat.com> I have pulled it out of rawhide. If you have updated and want to get your machine working again with SELinux you need to install selinux-policy-targeted-2.2.25-* you can do this with the following command rpm -Uhv --oldpackage selinux-policy-targeted-2.2.25-2 This will report an error but the correct files will have been placed on disk. Now if you execute semodule -n -b /usr/share/selinux/targeted/base.pp; touch /.autorelabel; reboot When this finishes your system should be back and running with selinux enabled. Policy was broken by a change to the policy tool chain that we are working to fix. Sorry about the problems this has caused. Dan From florin at andrei.myip.org Tue Mar 28 18:05:45 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Tue, 28 Mar 2006 10:05:45 -0800 Subject: SELinux FAQ problem Message-ID: <1143569145.2962.2.camel@rivendell.home.local> I am following the instructions found here to customize the policy: http://fedora.redhat.com/docs/selinux-faq-fc5/#id2784794 But I get this: ###################################################### # audit2allow -i audit.txt -M local -l Generating type enforcment file: local.te Compiling policy checkmodule -M -m -o local.mod local.te /usr/bin/audit2allow: sh: checkmodule: command not found ###################################################### The problem is, I have no idea what is "checkmodule". ###################################################### # which checkmodule /usr/bin/which: no checkmodule in (/usr/kerberos/sbin:/usr/kerberos/bin:/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin:/root/bin) # yum provides checkmodule Loading "installonlyn" plugin Searching Packages: Setting up repositories macromedia [1/5] livna [2/5] core [3/5] updates [4/5] extras [5/5] Reading repository metadata in from local files Importing additional filelist information No Matches found ###################################################### -- Florin Andrei http://florin.myip.org/ From sds at tycho.nsa.gov Tue Mar 28 18:22:05 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 28 Mar 2006 13:22:05 -0500 Subject: SELinux FAQ problem In-Reply-To: <1143569145.2962.2.camel@rivendell.home.local> References: <1143569145.2962.2.camel@rivendell.home.local> Message-ID: <1143570125.3037.88.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-03-28 at 10:05 -0800, Florin Andrei wrote: > I am following the instructions found here to customize the policy: > > http://fedora.redhat.com/docs/selinux-faq-fc5/#id2784794 > > But I get this: > > ###################################################### > # audit2allow -i audit.txt -M local -l > Generating type enforcment file: local.te > Compiling policy > checkmodule -M -m -o local.mod local.te > /usr/bin/audit2allow: sh: checkmodule: command not found > ###################################################### > > The problem is, I have no idea what is "checkmodule". yum install checkpolicy It contains both checkpolicy (compile monolithic policies) and checkmodule (compile modular policies). -- Stephen Smalley National Security Agency From i.pilcher at comcast.net Tue Mar 28 18:51:30 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 28 Mar 2006 12:51:30 -0600 Subject: SELinux denying chcon -- OUCH! Message-ID: A little background -- I have my music collection stored on 5 reiserfs filesystems, on top of five separate software RAID devices (md4-md8). I use httpd to make them available on my *home* network (and if the RIAA has a problem with that they can kiss my lilly-white...sorry). I generally mount them as /var/www/html/music/music{0,1,2,3,4}. Today I rebooted my system (Fedora Core 5, fully updated) and got some bizarre warnings about being unable to mount a block device read-only. Sure enough... audit(1143570731.388:11): avc: denied { mounton } for pid=1703 comm="mount" name="music0" dev=md1 ino=131232 scontext=system_u:system_r:mount_t:s0 tcontext=root:object_r:httpd_sys_content_t:s0 tclass=dir Hmm, looks like a special context is now needed for mount points. I can see why that might be a good idea, so... chcon system_u:system_r:mount_t /var/www/html/music/* chcon: failed to change context of /var/www/html/music/music0 to system_u:system_r:mount_t: Permission denied type=AVC msg=audit(1143571740.714:59): avc: denied { relabelto } for pid=3036 comm="chcon" name="music0" dev=md1 ino=131232 scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 tcontext=system_u:system_r:mount_t:s0 tclass=dir This is either a learning opportunity for me, or a serious problem. I can't wait to find out which. Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From sds at tycho.nsa.gov Tue Mar 28 20:45:31 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Tue, 28 Mar 2006 15:45:31 -0500 Subject: SELinux denying chcon -- OUCH! In-Reply-To: References: Message-ID: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-03-28 at 12:51 -0600, Ian Pilcher wrote: > A little background -- I have my music collection stored on 5 reiserfs > filesystems, on top of five separate software RAID devices (md4-md8). I > use httpd to make them available on my *home* network (and if the RIAA > has a problem with that they can kiss my lilly-white...sorry). I > generally mount them as /var/www/html/music/music{0,1,2,3,4}. > > Today I rebooted my system (Fedora Core 5, fully updated) and got some > bizarre warnings about being unable to mount a block device read-only. > Sure enough... > > audit(1143570731.388:11): avc: denied { mounton } for pid=1703 > comm="mount" name="music0" dev=md1 ino=131232 > scontext=system_u:system_r:mount_t:s0 > tcontext=root:object_r:httpd_sys_content_t:s0 tclass=dir > > Hmm, looks like a special context is now needed for mount points. I can > see why that might be a good idea, so... > > chcon system_u:system_r:mount_t /var/www/html/music/* > > chcon: failed to change context of /var/www/html/music/music0 to > system_u:system_r:mount_t: Permission denied > > type=AVC msg=audit(1143571740.714:59): avc: denied { relabelto } for > pid=3036 comm="chcon" name="music0" dev=md1 ino=131232 > scontext=user_u:system_r:unconfined_t:s0-s0:c0.c255 > tcontext=system_u:system_r:mount_t:s0 tclass=dir > > This is either a learning opportunity for me, or a serious problem. I > can't wait to find out which. mount_t is a domain - a type for a process running the mount program. Not a file type to assign to mount point directories. Not sure what type to recommend for what you describe - Dan? Likely need a generic mnt_t or similar with the mountpoint attribute? -- Stephen Smalley National Security Agency From i.pilcher at comcast.net Tue Mar 28 21:14:49 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 28 Mar 2006 15:14:49 -0600 Subject: SELinux denying chcon -- OUCH! In-Reply-To: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Stephen Smalley wrote: > > mount_t is a domain - a type for a process running the mount program. > Not a file type to assign to mount point directories. Not sure what > type to recommend for what you describe - Dan? Likely need a generic > mnt_t or similar with the mountpoint attribute? > I have changed the type of the mount points to mnt_t. It doesn't look like this will cause a problem for httpd, because once the filesystem is mounted, the type of its root directory appears to "mask" the type of the mount point. I should have mentioned before that I have no problem mounting these filesystems as a logged in root user (mount -a); the problem only occurs when booting the system. After changing the type of the mount points and rebooting, I am now getting this: audit(1143579721.063:15): avc: denied { search } for pid=1709 comm="mount" name="/" dev=md8 ino=2 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir It looks like the mount command is looking for something in the root directory of the filesystem, but I have no idea what that might be. Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From i.pilcher at comcast.net Tue Mar 28 21:52:09 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 28 Mar 2006 15:52:09 -0600 Subject: ReiserFS chicken and egg In-Reply-To: References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Ian Pilcher wrote: > audit(1143579721.063:15): avc: denied { search } for pid=1709 > comm="mount" name="/" dev=md8 ino=2 > scontext=system_u:system_r:mount_t:s0 > tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir I created a brand new ReiserFS filesystem on a spare device and tried to mount it on /mnt/tmp via /etc/fstab. Upon rebooting, dmesg contains: ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create .reiserfs_priv. Failing mount. So it looks like the mount command can't find the SELinux contexts for the filesystem, because the SELinux contexts for the filesystem aren't set, because it can't find the SELinux contexts for the filesystem.... -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From i.pilcher at comcast.net Wed Mar 29 00:03:16 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Tue, 28 Mar 2006 18:03:16 -0600 Subject: ReiserFS chicken and egg In-Reply-To: References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Ian Pilcher wrote: > > So it looks like the mount command can't find the SELinux contexts for > the filesystem, because the SELinux contexts for the filesystem aren't > set, because it can't find the SELinux contexts for the filesystem.... > I have the most fascinating conversations with myself... The following indicates that ReiserFS is simply broken with SELinux: https://www.redhat.com/archives/fedora-test-list/2006-January/msg00833.html -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From csellers at tresys.com Wed Mar 29 01:45:26 2006 From: csellers at tresys.com (Chad Sellers) Date: Tue, 28 Mar 2006 20:45:26 -0500 Subject: ANN: Fedora Core 5 SELinux FAQ Message-ID: <4429E6B6.7040108@tresys.com> The Fedora Core 5 SELinux FAQ is now available at http://fedora.redhat.com/docs/selinux-faq-fc5. Let me know if you have any corrections or suggestions. Also, check out the Fedora SELinux wiki at http://fedoraproject.org/wiki/SELinux, which includes a section for adding proposed additions to the FAQ. Thanks, Chad -- ---------------------- Chad Sellers Tresys Technology, LLC csellers at tresys.com http://www.tresys.com From sundaram at fedoraproject.org Wed Mar 29 01:49:36 2006 From: sundaram at fedoraproject.org (Rahul Sundaram) Date: Wed, 29 Mar 2006 07:19:36 +0530 Subject: ANN: Fedora Core 5 SELinux FAQ In-Reply-To: <4429E6B6.7040108@tresys.com> References: <4429E6B6.7040108@tresys.com> Message-ID: <1143596976.3802.587.camel@sundaram.pnq.redhat.com> On Tue, 2006-03-28 at 20:45 -0500, Chad Sellers wrote: > The Fedora Core 5 SELinux FAQ is now available at > http://fedora.redhat.com/docs/selinux-faq-fc5. Let me know if you have > any corrections or suggestions. Also, check out the Fedora SELinux wiki > at http://fedoraproject.org/wiki/SELinux, which includes a section for > adding proposed additions to the FAQ. > > Thanks, > Chad Thanks Chad. Good work. Rahul From florin at andrei.myip.org Wed Mar 29 08:08:31 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 29 Mar 2006 00:08:31 -0800 Subject: SELinux FAQ problem In-Reply-To: <1143570125.3037.88.camel@moss-spartans.epoch.ncsc.mil> References: <1143569145.2962.2.camel@rivendell.home.local> <1143570125.3037.88.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1143619711.2423.8.camel@rivendell.home.local> On Tue, 2006-03-28 at 13:22 -0500, Stephen Smalley wrote: > yum install checkpolicy > > It contains both checkpolicy (compile monolithic policies) and > checkmodule (compile modular policies). Cool, that solved it. Still, it might be a good idea to mention in the FAQ that the checkpolicy package needs to be installed, since it's not installed by default. -- Florin Andrei http://florin.myip.org/ From florin at andrei.myip.org Wed Mar 29 08:17:13 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Wed, 29 Mar 2006 00:17:13 -0800 Subject: autorelabel and changed security contexts Message-ID: <1143620233.2423.18.camel@rivendell.home.local> I've a FC4 server that's slightly customized: - /var/lib/imap and /var/spool/imap are moved to /home/cyrus (and /home is a separate partition) - /var/spool/squid is moved to another place (separate partition) - /var/lib/mysql is moved to another place (separate partition) - /var/log is on it's own partition I customized the policy so that Cyrus IMAPd can access /home/cyrus properly. But then I did "touch /.autorelabel; reboot" and Cyrus broke completely. Upon investigation, I noticed that the security contexts of the Cyrus folders in /home/cyrus were altered, from e.g. system_u:object_r:cyrus_var_lib_t to... I forgot to what - something else anyway. Questions: Why autorelabel changes the security contexts? How can I tell autorelabel to leave alone /home/cyrus (or give it the security contexts that I want those files to have)? I am asking these questions because I want to upgrade the server to FC5, keep the partitioning scheme, but avoid the multiple and annoying SELinux issues I had when I installed FC4 on that machine. So I guess the questions are at the same time for FC4 and FC5. -- Florin Andrei http://florin.myip.org/ From sds at tycho.nsa.gov Wed Mar 29 12:24:05 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Mar 2006 07:24:05 -0500 Subject: ReiserFS chicken and egg In-Reply-To: References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1143635045.20394.5.camel@moss-spartans.epoch.ncsc.mil> On Tue, 2006-03-28 at 15:52 -0600, Ian Pilcher wrote: > Ian Pilcher wrote: > > audit(1143579721.063:15): avc: denied { search } for pid=1709 > > comm="mount" name="/" dev=md8 ino=2 > > scontext=system_u:system_r:mount_t:s0 > > tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir > > I created a brand new ReiserFS filesystem on a spare device and tried to > mount it on /mnt/tmp via /etc/fstab. Upon rebooting, dmesg contains: > > ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create > .reiserfs_priv. Failing mount. > > So it looks like the mount command can't find the SELinux contexts for > the filesystem, because the SELinux contexts for the filesystem aren't > set, because it can't find the SELinux contexts for the filesystem.... Sorry, reiserfs xattrs are known to be broken with SELinux at present, because reiserfs doesn't yet implement the inode_init_security method for labeling new inodes atomically at creation time. As a workaround, mount it with a context= mount to override the use of xattrs. Dan and Chris - please drop the fs_use_xattr line for reiserfs in policy and possibly add a genfscon entry back for reiserfs so that SELinux doesn't try using xattrs on reiserfs. -- Stephen Smalley National Security Agency From i.pilcher at comcast.net Wed Mar 29 12:27:40 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 29 Mar 2006 06:27:40 -0600 Subject: ReiserFS chicken and egg In-Reply-To: <1143635045.20394.5.camel@moss-spartans.epoch.ncsc.mil> References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> <1143635045.20394.5.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Stephen Smalley wrote: > Sorry, reiserfs xattrs are known to be broken with SELinux at present, > because reiserfs doesn't yet implement the inode_init_security method > for labeling new inodes atomically at creation time. As a workaround, > mount it with a context= mount to override the use of xattrs. I tried context=system_u:object_r:file_t:s0 and got the same error. Is there something else I should be using? Thanks! -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From sds at tycho.nsa.gov Wed Mar 29 12:43:04 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Mar 2006 07:43:04 -0500 Subject: ReiserFS chicken and egg In-Reply-To: References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> <1143635045.20394.5.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1143636184.20394.24.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-29 at 06:27 -0600, Ian Pilcher wrote: > Stephen Smalley wrote: > > Sorry, reiserfs xattrs are known to be broken with SELinux at present, > > because reiserfs doesn't yet implement the inode_init_security method > > for labeling new inodes atomically at creation time. As a workaround, > > mount it with a context= mount to override the use of xattrs. > > I tried context=system_u:object_r:file_t:s0 and got the same error. Is > there something else I should be using? By the "same error", you mean another avc denial for search access to unlabeled_t:dir by mount_t? Did you get a SELinux: initialized (dev xxx, type reiserfs), uses mountpoint labeling message in /var/log/messages? -- Stephen Smalley National Security Agency From paul at city-fan.org Wed Mar 29 12:39:28 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Mar 2006 13:39:28 +0100 Subject: semanage / file_contexts.local Message-ID: <442A8000.2030908@city-fan.org> On my FC4 system, I created a file /etc/selinux/targeted/contexts/files/file_contexts.local that contained the following lines: /srv/backup(/.*)? system_u:object_r:ftpd_anon_rw_t /srv/softlib(/.*)? system_u:object_r:ftpd_anon_rw_t This was to ensure that that files created in these areas got the right context, and that it would survive a relabel. Having since learned about customizable types, I probably didn't need to do that in this case, but the principle applies anyway. My understanding is that in FC5, the equivalent thing to do for this would be to use semanage to add additional fcontext objects. Is that right (I think the semanage manpage could do with an example or two btw, hint, hint)? My first question is: if I use semanage, is there a convenient way to check, on a running system, which objects are there as part of the base policy and which have been added later, like a file context equivalent of "semodule -l"? My second question is: I have lots of log messages like this: Mar 26 04:24:39 badby kernel: inode_doinit_with_dentry: context_to_sid(system_u:object_r:ftpd_anon_rw_t) returned 22 for dev=sdb6 ino=96769 Google suggests that this is a hangover from FC4 that shouldn't be there, and I suspect is has to do with the presence of my /etc/selinux/targeted/contexts/files/file_contexts.local file. I'm thinking of changing this to: /srv/backup(/.*)? system_u:object_r:public_content_rw_t:s0 /srv/softlib(/.*)? system_u:object_r:public_content_rw_t:s0 or even deleting it entirely and doing the equivalent with semanage. When I do one of these things, when will it take effect? Will I need to reboot, or rebuild policy somehow? Paul. From sds at tycho.nsa.gov Wed Mar 29 13:09:01 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Mar 2006 08:09:01 -0500 Subject: semanage / file_contexts.local In-Reply-To: <442A8000.2030908@city-fan.org> References: <442A8000.2030908@city-fan.org> Message-ID: <1143637741.20394.31.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-29 at 13:39 +0100, Paul Howarth wrote: > On my FC4 system, I created a file > /etc/selinux/targeted/contexts/files/file_contexts.local that contained > the following lines: > > /srv/backup(/.*)? system_u:object_r:ftpd_anon_rw_t > /srv/softlib(/.*)? system_u:object_r:ftpd_anon_rw_t > > This was to ensure that that files created in these areas got the right > context, and that it would survive a relabel. Having since learned about > customizable types, I probably didn't need to do that in this case, but > the principle applies anyway. > > My understanding is that in FC5, the equivalent thing to do for this > would be to use semanage to add additional fcontext objects. Is that > right (I think the semanage manpage could do with an example or two btw, > hint, hint)? Funny you should ask. See http://marc.theaimsgroup.com/?l=selinux&m=114358806507499&w=2 > My first question is: if I use semanage, is there a convenient way to > check, on a running system, which objects are there as part of the base > policy and which have been added later, like a file context equivalent > of "semodule -l"? Hmm...doesn't look like semanage presently has an option that invokes just the xxx_list_local() interface of libsemanage versus the xxx_list() interface. Seems like a good idea. > My second question is: I have lots of log messages like this: > > Mar 26 04:24:39 badby kernel: inode_doinit_with_dentry: > context_to_sid(system_u:object_r:ftpd_anon_rw_t) returned 22 for > dev=sdb6 ino=96769 Suggests that the type is no longer defined, which seems a bit surprising. Usually we add a type alias to keep it valid across updates. > /srv/backup(/.*)? system_u:object_r:public_content_rw_t:s0 > /srv/softlib(/.*)? system_u:object_r:public_content_rw_t:s0 > > or even deleting it entirely and doing the equivalent with semanage. > When I do one of these things, when will it take effect? Will I need to > reboot, or rebuild policy somehow? file_contexts.local will still be read by libselinux (matchpathcon), so it can still be used, but using semanage is likely the better way forward. Once you've run the semanage command, it should rebuild and push out an updated file_contexts file with your additions included, and then any subsequent runs of restorecon/setfiles/... will make use of those definitions. -- Stephen Smalley National Security Agency From paul at city-fan.org Wed Mar 29 13:27:07 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Mar 2006 14:27:07 +0100 Subject: semanage / file_contexts.local In-Reply-To: <1143637741.20394.31.camel@moss-spartans.epoch.ncsc.mil> References: <442A8000.2030908@city-fan.org> <1143637741.20394.31.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <442A8B2B.9030301@city-fan.org> Stephen Smalley wrote: > On Wed, 2006-03-29 at 13:39 +0100, Paul Howarth wrote: >> On my FC4 system, I created a file >> /etc/selinux/targeted/contexts/files/file_contexts.local that contained >> the following lines: >> >> /srv/backup(/.*)? system_u:object_r:ftpd_anon_rw_t >> /srv/softlib(/.*)? system_u:object_r:ftpd_anon_rw_t >> >> This was to ensure that that files created in these areas got the right >> context, and that it would survive a relabel. Having since learned about >> customizable types, I probably didn't need to do that in this case, but >> the principle applies anyway. >> >> My understanding is that in FC5, the equivalent thing to do for this >> would be to use semanage to add additional fcontext objects. Is that >> right (I think the semanage manpage could do with an example or two btw, >> hint, hint)? > > Funny you should ask. See > http://marc.theaimsgroup.com/?l=selinux&m=114358806507499&w=2 Ah, good :-) >> My first question is: if I use semanage, is there a convenient way to >> check, on a running system, which objects are there as part of the base >> policy and which have been added later, like a file context equivalent >> of "semodule -l"? > > Hmm...doesn't look like semanage presently has an option that invokes > just the xxx_list_local() interface of libsemanage versus the xxx_list() > interface. Seems like a good idea. > >> My second question is: I have lots of log messages like this: >> >> Mar 26 04:24:39 badby kernel: inode_doinit_with_dentry: >> context_to_sid(system_u:object_r:ftpd_anon_rw_t) returned 22 for >> dev=sdb6 ino=96769 > > Suggests that the type is no longer defined, which seems a bit > surprising. Usually we add a type alias to keep it valid across > updates. > >> /srv/backup(/.*)? system_u:object_r:public_content_rw_t:s0 >> /srv/softlib(/.*)? system_u:object_r:public_content_rw_t:s0 >> >> or even deleting it entirely and doing the equivalent with semanage. >> When I do one of these things, when will it take effect? Will I need to >> reboot, or rebuild policy somehow? > > file_contexts.local will still be read by libselinux (matchpathcon), so > it can still be used, but using semanage is likely the better way > forward. Once you've run the semanage command, it should rebuild and > push out an updated file_contexts file with your additions included, and > then any subsequent runs of restorecon/setfiles/... will make use of > those definitions. Right, I moved the existing /etc/selinux/targeted/contexts/files/file_contexts.local out of the way and did: # semanage fcontext -a -t public_content_rw_t '/srv/backup(/.*)?' # semanage fcontext -a -t public_content_rw_t '/srv/softlib(/.*)?' This then created a new /etc/selinux/targeted/contexts/files/file_contexts.local, which contained: # This file is auto-generated by libsemanage # Please use the semanage command to make changes /srv/backup(/.*)? system_u:object_r:public_content_rw_t:s0 /srv/softlib(/.*)? system_u:object_r:public_content_rw_t:s0 So it seems that I can identify local changes by looking in the file (pretty much as before really, except that the file is created using semanage rather than vi). One last thing: is it possible to add multiple objects in a single semanage call? I ask because each one takes a while to run (to do the rebuild), and I can imagine that in an RPM package where there might be lots of calls to semanage being made in a %post scriptlet, it would be better to add all the objects at once and only do a single rebuild. Paul. From ivg2 at cornell.edu Wed Mar 29 14:47:22 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 29 Mar 2006 09:47:22 -0500 Subject: semanage / file_contexts.local In-Reply-To: <442A8B2B.9030301@city-fan.org> References: <442A8000.2030908@city-fan.org> <1143637741.20394.31.camel@moss-spartans.epoch.ncsc.mil> <442A8B2B.9030301@city-fan.org> Message-ID: <442A9DFA.2080405@cornell.edu> > > So it seems that I can identify local changes by looking in the file > (pretty much as before really, except that the file is created using > semanage rather than vi). Right... the idea behind semanage is that it should support multiple backends. Right now it supports flat file, policy object representation (via libsepol), and selinuxfs for booleans (via libselinux). In the future we want to support more backends, such as LDAP, and a policy management server being developed by Tresys. This server should allow more fine-grained access controls over policy modifications than we currently have with the flat file. Also, it should move towards distributed management over a network. So, while the representation is the same right now, it may not stay that way in the future. We'll likely make the store readable only by semanage utilities in enforcing mode. > > One last thing: is it possible to add multiple objects in a single > semanage call? I don't think the python frontend supports it, but the backend library certainly does - it's transactional, and only the commit takes a long time. It seems like this would be useful to people - Dan? > I ask because each one takes a while to run (to do the rebuild), and I > can imagine that in an RPM package where there might be lots of calls > to semanage being made in a %post scriptlet, it would be better to add > all the objects at once and only do a single rebuild. Not sure of the status of rpm integration w/ modules, Dan would be the person to ask... Rpm would have to make use of the transactional mechanism, not only because of speed, but because inter-module dependencies get resolved that way [ speaking of which, do policy module dependencies match rpm dependencies? ]. From dwalsh at redhat.com Wed Mar 29 14:53:45 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 29 Mar 2006 09:53:45 -0500 Subject: SELinux overview on line. Message-ID: <442A9F79.6010309@redhat.com> http://www.redhat.com/v/swf/SELinux/ Dan From ivg2 at cornell.edu Wed Mar 29 15:12:17 2006 From: ivg2 at cornell.edu (Ivan Gyurdiev) Date: Wed, 29 Mar 2006 10:12:17 -0500 Subject: semanage / file_contexts.local In-Reply-To: <442A9DFA.2080405@cornell.edu> References: <442A8000.2030908@city-fan.org> <1143637741.20394.31.camel@moss-spartans.epoch.ncsc.mil> <442A8B2B.9030301@city-fan.org> <442A9DFA.2080405@cornell.edu> Message-ID: <442AA3D1.3070309@cornell.edu> >> I ask because each one takes a while to run (to do the rebuild), By the way, in the case of contexts, the rebuild is completely avoidable. With some code reorganization, it's easy to optimize this out. Maybe I'll take a look after more important issues are dealt with... --> /* FIXME: get rid of these, once we support loading the existing policy, * instead of rebuilding it */ modified |= seusers_modified; modified |= fcontexts_modified; modified |= users_extra_modified; From sds at tycho.nsa.gov Wed Mar 29 15:39:40 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Mar 2006 10:39:40 -0500 Subject: semanage / file_contexts.local In-Reply-To: <442A9DFA.2080405@cornell.edu> References: <442A8000.2030908@city-fan.org> <1143637741.20394.31.camel@moss-spartans.epoch.ncsc.mil> <442A8B2B.9030301@city-fan.org> <442A9DFA.2080405@cornell.edu> Message-ID: <1143646780.20394.65.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-29 at 09:47 -0500, Ivan Gyurdiev wrote: > > One last thing: is it possible to add multiple objects in a single > > semanage call? > I don't think the python frontend supports it, but the backend library > certainly does - it's transactional, and only the commit takes a long > time. It seems like this would be useful to people - Dan? Not sure what the user interface would look like. semodule already supports multiple operations on a single command line, e.g. semodule -b base.pp -i a.pp -i b.pp but semanage syntax is a bit more complicated. Are we talking about just adding multiple objects of the same type in a single command, e.g. collapsing semanage port -a -t http_port_t -p tcp 81 semanage port -a -t http_cache_port_t -p tcp 8081 to something like: semanage port -a -t http_port_t -p tcp 81 -a -t http_cache_port_t -p tcp 8080 Or dealing with arbitrary combinations, e.g. collapsing semanage port -a -t http_port_t -p tcp 81 semanage fcontext -a -t httpd_sys_content_t '/web(/.*)?' to some single command line? -- Stephen Smalley National Security Agency From paul at city-fan.org Wed Mar 29 15:41:17 2006 From: paul at city-fan.org (Paul Howarth) Date: Wed, 29 Mar 2006 16:41:17 +0100 Subject: semanage / file_contexts.local In-Reply-To: <1143646780.20394.65.camel@moss-spartans.epoch.ncsc.mil> References: <442A8000.2030908@city-fan.org> <1143637741.20394.31.camel@moss-spartans.epoch.ncsc.mil> <442A8B2B.9030301@city-fan.org> <442A9DFA.2080405@cornell.edu> <1143646780.20394.65.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <442AAA9D.8070903@city-fan.org> Stephen Smalley wrote: > On Wed, 2006-03-29 at 09:47 -0500, Ivan Gyurdiev wrote: >>> One last thing: is it possible to add multiple objects in a single >>> semanage call? >> I don't think the python frontend supports it, but the backend library >> certainly does - it's transactional, and only the commit takes a long >> time. It seems like this would be useful to people - Dan? > > Not sure what the user interface would look like. semodule already > supports multiple operations on a single command line, e.g. > semodule -b base.pp -i a.pp -i b.pp > but semanage syntax is a bit more complicated. > > Are we talking about just adding multiple objects of the same type in a > single command, e.g. collapsing > semanage port -a -t http_port_t -p tcp 81 > semanage port -a -t http_cache_port_t -p tcp 8081 > to something like: > semanage port -a -t http_port_t -p tcp 81 -a -t http_cache_port_t -p tcp 8080 > > Or dealing with arbitrary combinations, e.g. collapsing > semanage port -a -t http_port_t -p tcp 81 > semanage fcontext -a -t httpd_sys_content_t '/web(/.*)?' > to some single command line? That would result in a very complex command-line parser and be difficult for users as well as developers. It could get even worse, such as wanting to combine add and modify operations. An alternative approach might be to provide an option to skip the policy rebuild. That way you could do a string of semanage commands and use the "skip rebuild" option on all but the last of them. Paul. From geez4 at runbox.com Wed Mar 29 16:54:01 2006 From: geez4 at runbox.com (Gary Kopp) Date: Wed, 29 Mar 2006 09:54:01 -0700 Subject: Targeted strategy guidance needed Message-ID: <00b501c65351$628b23a0$8103a8c0@rokswdev.local> Would someone on this list be able to take a moment to give me a sanity check and tell me if I'm on the right track? I'm configuring a RHEL4 server to be an Internet-facing web/mail server. It will run httpd, postfix, and courier-imap. Most application logic (including any requirement for SQL access) will live on other servers that I'm not concerned about in the context of SELinux, but this web server will probably have to run one PHP application (Blog:CMS). I desire this web server to be as secure as possible. I have not yet mastered the intricacies of SELinux (but I'm working on that), and I thought that by using Red Hat's targeted SELinux policy I'd have a head start. I also thought this would leverage my investment in the Red Hat Enterprise Linux support contract, being able to turn to Red Hat support for help. I have since found out that my support agreement (SLA) does not cover any SELinux issues arising from a modified targeted policy. And right out of the chute I see that I can't live with the targeted policy as delivered, and need to tweak it. For example, this server uses syslog-ng, and the targeted policy is already complaining. Red Hat's SELinux Guide offers instructions on how to add rules to local.te to get around minor issues like this, and I'm willing to do that, but then I'll have no support from Red Hat directly. I also anticipate that my httpd config may require some policy tweaks (e.g., I'm thinking of putting Apache logs in a non-standard location). Next, the delivered targeted policy doesn't constrain postfix (it seems to reference postfix, but then aliases it to unconfined). Again, the Guide suggests I could write new policy specifically for something like postfix, in essence extending the targeted policy. Interestingly, I see that the gentoo project has a whole bunch of SELinux policies available, including one for postfix. A side question I have is: does it make sense to adapt/use the policies available in the gentoo project to extend the targeted policy for new processes, or is that a bad idea? I'm assuming that the RHEL targeted policy and the FC policy, the subject of this mailing list, are one and the same, and therefore I'm not out of line coming to this list. Am I correct? As a RHEL user rather than a FC user can I still use this list as a resource? OK, here's my fundamental question: Given what I'm trying to achieve, is my proper approach to start tweaking and extending the delivered targeted policy? Is that commonly done, or should I be looking at some other strategy to meet my needs? I'll be grateful for any advice anyone would like to offer. TIA --Gary Kopp From smooge at gmail.com Wed Mar 29 17:19:07 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 29 Mar 2006 10:19:07 -0700 Subject: ANN: Fedora Core 5 SELinux FAQ In-Reply-To: <4429E6B6.7040108@tresys.com> References: <4429E6B6.7040108@tresys.com> Message-ID: <80d7e4090603290919j7fbe917ctb8e0fbd1e83a02d8@mail.gmail.com> On 3/28/06, Chad Sellers wrote: > The Fedora Core 5 SELinux FAQ is now available at > http://fedora.redhat.com/docs/selinux-faq-fc5. Let me know if you have > any corrections or suggestions. Also, check out the Fedora SELinux wiki > at http://fedoraproject.org/wiki/SELinux, which includes a section for > adding proposed additions to the FAQ. > Cool and thanks for all the work here. I am trying to go over the questions in here one by one.. as I need to work out what could be done for some systems where I work. I have one question so far: Q: What about the strict policy? Does it even work? [From the list at release time.. I thought strict policy was broken for Core.] Q: What is the Reference Policy? [I found I am really confused by this answer.. if my muddled brain is getting this correct.. the Reference Policy is the base policy that the Fedora Core 5 targeted, strict, mls policies are based off of the Reference Policy.. or are there 2 sets of policies shipped with Fedora Core 5 some of which are based off of the old set and the others by the new set.] Again thanks.. I will try to send some stuff as I go through this. -- Stephen J Smoogen. CSIRT/Linux System Administrator From sds at tycho.nsa.gov Wed Mar 29 17:53:34 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Mar 2006 12:53:34 -0500 Subject: ANN: Fedora Core 5 SELinux FAQ In-Reply-To: <80d7e4090603290919j7fbe917ctb8e0fbd1e83a02d8@mail.gmail.com> References: <4429E6B6.7040108@tresys.com> <80d7e4090603290919j7fbe917ctb8e0fbd1e83a02d8@mail.gmail.com> Message-ID: <1143654814.24555.21.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-29 at 10:19 -0700, Stephen J. Smoogen wrote: > I am trying to go over the questions in here one by one.. as I need to > work out what could be done for some systems where I work. I have one > question so far: > > Q: What about the strict policy? Does it even work? > [From the list at release time.. I thought strict policy was broken > for Core.] Yes, -strict in FC5 is broken at the moment, although there is ongoing work to resolve the issues needed to get it working. The breakage isn't really anything to do with -strict per se, just fully modularized policy (breaking down even the base policy into lots of individual modules). > Q: What is the Reference Policy? > > [I found I am really confused by this answer.. if my muddled brain > is getting this correct.. the Reference Policy is the base policy that > the Fedora Core 5 targeted, strict, mls policies are based off of the > Reference Policy.. or are there 2 sets of policies shipped with Fedora > Core 5 some of which are based off of the old set and the others by > the new set.] Reference policy is the new source policy tree from which all policy types (-strict, -targeted, -mls) are being built. Previously, they were being built from the NSA example policy source tree. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Wed Mar 29 18:03:24 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Wed, 29 Mar 2006 13:03:24 -0500 Subject: ANN: Fedora Core 5 SELinux FAQ In-Reply-To: <1143654814.24555.21.camel@moss-spartans.epoch.ncsc.mil> References: <4429E6B6.7040108@tresys.com> <80d7e4090603290919j7fbe917ctb8e0fbd1e83a02d8@mail.gmail.com> <1143654814.24555.21.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1143655404.24555.31.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-29 at 12:53 -0500, Stephen Smalley wrote: > > Q: What is the Reference Policy? > > > > [I found I am really confused by this answer.. if my muddled brain > > is getting this correct.. the Reference Policy is the base policy that > > the Fedora Core 5 targeted, strict, mls policies are based off of the > > Reference Policy.. or are there 2 sets of policies shipped with Fedora > > Core 5 some of which are based off of the old set and the others by > > the new set.] > > Reference policy is the new source policy tree from which all policy > types (-strict, -targeted, -mls) are being built. Previously, they were > being built from the NSA example policy source tree. I'm guessing that you were confused by this statement from the FAQ: "Fedora policies at version 1.x are based on the traditional example policy. Version 2.x policies (as used in Fedora Core 5) are based on the Reference Policy." This doesn't mean that there are two branches of policy (1.x and 2.x) being carried in FC5; FC5 only has version 2.x.y policies based on refpolicy. The above statement from the FAQ just means that when the developers switched from using example policy to reference policy as their source base during development of FC5, they changed the package version from being a 1.x series to being a 2.x series to signify that a major change had occurred. So when you see a policy package that has a 1.x version, you know you are dealing with a policy built from example policy (as in FC4, RHEL4, FC3), and when you see a 2.x version, you know you are dealing with a policy built from refpolicy (as in FC5 and everything going forward). -- Stephen Smalley National Security Agency From i.pilcher at comcast.net Wed Mar 29 19:34:59 2006 From: i.pilcher at comcast.net (Ian Pilcher) Date: Wed, 29 Mar 2006 13:34:59 -0600 Subject: ReiserFS chicken and egg In-Reply-To: <1143636184.20394.24.camel@moss-spartans.epoch.ncsc.mil> References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> <1143635045.20394.5.camel@moss-spartans.epoch.ncsc.mil> <1143636184.20394.24.camel@moss-spartans.epoch.ncsc.mil> Message-ID: Stephen Smalley wrote: > On Wed, 2006-03-29 at 06:27 -0600, Ian Pilcher wrote: >> Stephen Smalley wrote: >>> Sorry, reiserfs xattrs are known to be broken with SELinux at present, >>> because reiserfs doesn't yet implement the inode_init_security method >>> for labeling new inodes atomically at creation time. As a workaround, >>> mount it with a context= mount to override the use of xattrs. >> I tried context=system_u:object_r:file_t:s0 and got the same error. Is >> there something else I should be using? > > By the "same error", you mean another avc denial for search access to > unlabeled_t:dir by mount_t? Did you get a SELinux: initialized (dev > xxx, type reiserfs), uses mountpoint labeling message > in /var/log/messages? > Sorry about the delay...jury duty. Just tried again to be sure: mkfs.reiserfs /dev/md9 /etc/fstab contains: /dev/md9 /mnt/tmp reiserfs context=system_u:object_r:file_t:s0 0 2 Rebooted and the mount failed. dmesg | grep md9 shows: audit(1143660461.416:15): avc: denied { search } for pid=1714 comm="mount" name="/" dev=md9 ino=2 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create .reiserfs_priv. Failing mount. It doesn't look like the context option had any affect at all. -- ======================================================================== Ian Pilcher i.pilcher at comcast.net ======================================================================== From dwalsh at redhat.com Wed Mar 29 21:14:57 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 29 Mar 2006 16:14:57 -0500 Subject: autorelabel and changed security contexts In-Reply-To: <1143620233.2423.18.camel@rivendell.home.local> References: <1143620233.2423.18.camel@rivendell.home.local> Message-ID: <442AF8D1.8060708@redhat.com> Florin Andrei wrote: > I've a FC4 server that's slightly customized: > - /var/lib/imap and /var/spool/imap are moved to /home/cyrus (and /home > is a separate partition) > - /var/spool/squid is moved to another place (separate partition) > - /var/lib/mysql is moved to another place (separate partition) > - /var/log is on it's own partition > > I customized the policy so that Cyrus IMAPd can access /home/cyrus > properly. But then I did "touch /.autorelabel; reboot" and Cyrus broke > completely. Upon investigation, I noticed that the security contexts of > the Cyrus folders in /home/cyrus were altered, from e.g. > system_u:object_r:cyrus_var_lib_t to... I forgot to what - something > else anyway. > > Questions: > > Why autorelabel changes the security contexts? > > How can I tell autorelabel to leave alone /home/cyrus (or give it the > security contexts that I want those files to have)? > You need to modify file_context.local to match the context you want. > I am asking these questions because I want to upgrade the server to FC5, > keep the partitioning scheme, but avoid the multiple and annoying > SELinux issues I had when I installed FC4 on that machine. > > So I guess the questions are at the same time for FC4 and FC5. > > In fc5 you can use semanage to make these changes. From dwalsh at redhat.com Wed Mar 29 23:28:45 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Wed, 29 Mar 2006 18:28:45 -0500 Subject: Need testers for Modules policicy on RHEL4 Message-ID: <442B182D.9060104@redhat.com> I have back ported the entire selinux tool chain to RHEL4. I have also attempted to create a modular policy to match RHEL4 policy as closely as possible. These packages are out on ftp://people.redhat.com/dwalsh/SELinux/RHEL4_MODULAR If anyone wants to play with these and do some testing that would be great. There is no commitment from Red Hat to ever ship this. But if it is ever going to ship, we need to find problems with it now. So if you have a spare RHEL4 box and want to play with modular policy, this is your chance. Thanks, Dan From smooge at gmail.com Wed Mar 29 23:44:27 2006 From: smooge at gmail.com (Stephen J. Smoogen) Date: Wed, 29 Mar 2006 16:44:27 -0700 Subject: Need testers for Modules policicy on RHEL4 In-Reply-To: <442B182D.9060104@redhat.com> References: <442B182D.9060104@redhat.com> Message-ID: <80d7e4090603291544m3096f484he2c4552cd6ec66a8@mail.gmail.com> On 3/29/06, Daniel J Walsh wrote: > I have back ported the entire selinux tool chain to RHEL4. I have also > attempted to create a modular policy to match RHEL4 policy as closely as > possible. > > These packages are out on > > ftp://people.redhat.com/dwalsh/SELinux/RHEL4_MODULAR > > If anyone wants to play with these and do some testing that would be great. Cool. I realize there is no promise but I will try them on a test box. What should I look for in a test plan? Also what is the difference between selinux-policy-2.2.28-1.rhel4.noarch.rpm and selinux-policy-targeted-2.2.28-1.rhel4.noarch.rpm? > > There is no commitment from Red Hat to ever ship this. But if it is > ever going to ship, > we need to find problems with it now. > > So if you have a spare RHEL4 box and want to play with modular policy, > this is your chance. > > Thanks, > > > Dan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > -- Stephen J Smoogen. CSIRT/Linux System Administrator From sds at tycho.nsa.gov Thu Mar 30 13:41:55 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 30 Mar 2006 08:41:55 -0500 Subject: ReiserFS chicken and egg In-Reply-To: References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> <1143635045.20394.5.camel@moss-spartans.epoch.ncsc.mil> <1143636184.20394.24.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <1143726115.24555.143.camel@moss-spartans.epoch.ncsc.mil> On Wed, 2006-03-29 at 13:34 -0600, Ian Pilcher wrote: > Sorry about the delay...jury duty. > > Just tried again to be sure: > > mkfs.reiserfs /dev/md9 > > /etc/fstab contains: > > /dev/md9 /mnt/tmp reiserfs context=system_u:object_r:file_t:s0 0 2 > > Rebooted and the mount failed. dmesg | grep md9 shows: > > audit(1143660461.416:15): avc: denied { search } for pid=1714 > comm="mount" name="/" dev=md9 ino=2 > scontext=system_u:system_r:mount_t:s0 > tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir > ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create > .reiserfs_priv. Failing mount. > > It doesn't look like the context option had any affect at all. I think we are encountering the denial before we reach the processing of the context option. The setup of the superblock security data and the root directory security data happens upon security_sb_kern_mount, but this is called after the filesystem returns from its get_sb method. Unfortunately, reiserfs apparently tries to access the xattr directory during get_sb, so there is an attempted lookup before SELinux has initialized the security state on the root directory, and we get a denial on unlabeled_t. I guess you need to allow mount_t unlabeled_t:dir search; to workaround it. -- Stephen Smalley National Security Agency From justin.conover at gmail.com Thu Mar 30 17:48:38 2006 From: justin.conover at gmail.com (Justin Conover) Date: Thu, 30 Mar 2006 11:48:38 -0600 Subject: rawhide report: 20060330 changes In-Reply-To: <200603301513.k2UFD2Hp006793@porkchop.devel.redhat.com> References: <200603301513.k2UFD2Hp006793@porkchop.devel.redhat.com> Message-ID: On 3/30/06, Build System wrote: > > New package xorg-x11-drv-vmmouse > Xorg X11 vmmouse input driver > > > > Updated Packages: > > bind-30:9.3.2-14.FC6 > -------------------- > * Wed Mar 29 2006 Jason Vsa Dias - 30:9.3.2-14 > - fix bug 186577: remove -L/usr/lib from libbind.pc and more .spec file > cleanup > - add '%doc' sample configuration files in /usr/share/doc/bind*/sample > - rebuild with new gcc and glibc > > ethereal-0.10.14-4.svn.1 > ------------------------ > * Wed Mar 29 2006 Radek Vok?l 0.10.14-4.svn.1 > - update to latest svn version > - dumpcap > > fedora-release-5.89-rawhide > --------------------------- > > gcc-4.1.0-4 > ----------- > * Tue Mar 28 2006 Jakub Jelinek 4.1.0-4 > - update from gcc-4_1-branch (-r111697:112431) > - PRs ada/25885, c/26004, fortran/17298, fortran/20935, fortran/20938, > fortran/23092, fortran/24519, fortran/24557, fortran/25045, > fortran/25054, fortran/25075, fortran/25089, fortran/25378, > fortran/25395, fortran/26041, fortran/26054, fortran/26064, > fortran/26107, fortran/26277, fortran/26393, fortran/26716, > fortran/26741, libfortran/21303, libfortran/24903, libgcj/24461, > libgcj/25713, libgcj/26103, libgcj/26688, libgcj/26706, > libgfortran/26499, libgfortran/26509, libgfortran/26554, > libgfortran/26661, libgfortran/26880, libstdc++/26132, > middle-end/18859, middle-end/19543, middle-end/26557, > middle-end/26630, other/26489, target/25917, target/26347, > target/26459, target/26532, target/26607, tree-optimization/26524, > tree-optimization/26587, tree-optimization/26672 > - fix visibility and builtins interaction (Jason Merrill, > PR middle-end/20297, #175442) > - merge gomp changes from trunk (-r112022:112023, -r112250:112251, > -r112252:112253, -r112350:112351 and -r112282:112283) > - PRs c++/26691, middle-end/26084, middle-end/26611, c++/26690, > middle-end/25989 > - support visibility attribute on namespaces (Jason Merrill, PR c++/21764, > PR c++/19238) > - use hidden visibility for anonymous namespaces by default (Jason > Merrill, > PR c++/21581) > > gnome-pilot-2.0.13-8 > -------------------- > * Wed Mar 29 2006 Than Ngo 2.0.13-8 > - rebuilt against pilot-link-0.11.8 > > gnome-pilot-conduits-2.0.13-4 > ----------------------------- > * Wed Mar 29 2006 Than Ngo 2.0.13-4 > - rebuilt against pilot-link-0.11.8 > - don't apply gnome-pilot-conduits-2.0.13-port-to-pilot-link-0.12.patch > > iputils-20020927-37 > ------------------- > * Wed Mar 29 2006 Radek Vok?l - 20020927-37 > - fix ifenslave, shows interface addresses > - add RPM_OPT_FLAGS to ifenslave > > * Sun Mar 12 2006 Radek Vok?l - 20020927-36 > - fix ifenslave man page (#185223) > > jpilot-0.99.8-4 > --------------- > * Wed Mar 29 2006 Than Ngo 0.99.8-4 > - rebuilt against pilot-link-0.11.8 > > kernel-2.6.16-1.2104_FC6 > ------------------------ > * Wed Mar 29 2006 Dave Jones > - 2.6.16-git16 & git17 > > libsepol-1.12.4-1 > ----------------- > * Wed Mar 29 2006 Dan Walsh 1.12.4-1 > - Upgrade to latest from NSA > * Generalize test for bitmap overflow in ebitmap_set_bit. > > logrotate-3.7.3-3 > ----------------- > * Tue Mar 28 2006 Peter Vrabec 3.7.3-3 > - correct man page "extension" option description (#185318) > > ncpfs-2.2.6-2 > ------------- > * Wed Mar 29 2006 Martin Stransky 2.2.6-2 > - removed opt flags (#186683) > > openoffice.org-1:2.0.2-5.7.3 > ---------------------------- > * Wed Mar 29 2006 Caolan McNamara - 1:2.0.2-5.7 > - rh#186747# TTF conts converted to Type 1 in print to file ps > > * Tue Mar 28 2006 Caolan McNamara - 1:2.0.2-5.6 > - more rh#186215#/ooo#63583# accessibility fixes > - better fallback to english if help is missing > > pam_krb5-2.2.8-1 > ---------------- > * Wed Mar 29 2006 Nalin Dahyabhai - 2.2.8-1 > - don't try to validate creds in a password-changing situation, because > the > attempt will always fail unless the matching key is in the keytab, which > should never be the case for the password-changing service (#187303, > rbasch) > - if v4 has been disabled completely, go ahead and try to set 2b tokens > because we're going to end up having to do that anyway (#182378) > > * Fri Mar 10 2006 Nalin Dahyabhai - 2.2.7-2 > - fixup man page conflicts in %install > > * Wed Mar 08 2006 Bill Nottingham - 2.2.6-2.2 > - don't use paths in man pages - avoids multilib conflicts > > pilot-link-2:0.11.8-14 > ---------------------- > * Wed Mar 29 2006 Than Ngo 2:0.11.8-14 > - rebuild to get rid of libpisock.so.9 > > * Wed Mar 29 2006 Than Ngo 2:0.11.8-13 > - downgrade to stable release 0.11.8 > > policycoreutils-1.30.4-1 > ------------------------ > * Wed Mar 29 2006 Dan Walsh 1.30.4-1 > - Update from upstream > * Merged audit2allow fixes for refpolicy from Dan Walsh. > * Merged fixfiles patch from Dan Walsh. > * Merged restorecond daemon from Dan Walsh. > * Merged semanage non-MLS fixes from Chris PeBenito. > * Merged semanage and semodule man page examples from Thomas > Bleher. > > * Tue Mar 28 2006 Dan Walsh 1.30.1-4 > - Clean up reference policy generation in audit2allow > > scim-1.4.4-9.1.fc5 > ------------------ > * Wed Mar 29 2006 Jens Petersen - 1.4.4-9.1.fc5 > - make scim-libs prereq libstdc++so7 to avoid update-gtk-immodules error > when > installing on i386 (#186365) > - setup xinput.d for some more locale (as_IN, or_IN, si_LK, vi_VN, and > zh_HK) > > * Thu Mar 02 2006 Jens Petersen - 1.4.4-9 > - make scim-libs prereq gtk2 > 2.8 to avoid update-gtk-immodules error > when upgrading from FC4 (#183636) > > * Wed Mar 01 2006 Jens Petersen - 1.4.4-8 > - add scim-system-default-config.patch > - add Zenkaku_Hankaku as trigger hotkey for Japanese users > - use static XIM event flow so deadkeys work under XIM in off state > (#169975) > - add alternatives as prereq for %post and %postun (pknirsch, #182853) > > scim-hangul-0.2.2-1.fc6 > ----------------------- > * Thu Mar 30 2006 Akira TAGOH - 0.2.2-1 > - New upstream release. > > selinux-policy-2.2.28-1 > ----------------------- > * Mon Mar 27 2006 Dan Walsh 2.2.28-1 > - Update to upstream > > * Wed Mar 22 2006 Dan Walsh 2.2.27-1 > - Update to upstream > > * Wed Mar 22 2006 Dan Walsh 2.2.25-3 > - Fix policyhelp > > squid-7:2.5.STABLE13-3 > ---------------------- > * Wed Mar 29 2006 Martin Stransky - 7:2.5.STABLE13-3 > - improved pre script (#187217) - added group switch > > sysreport-1.4.3-5 > ----------------- > * Tue Mar 28 2006 Than Ngo 1.4.3-5 > - use LANG=C > > * Tue Mar 14 2006 Than Ngo 1.4.3-4 > - add the correct option to collect iptables information (mangle) #181299 > - collect shared memory Segments info #181681 > > system-config-samba-1.2.35-1 > ---------------------------- > * Wed Mar 29 2006 Nils Philippsen - 1.2.35 > - don't require gnome module (#187200) > - don't wrap text in About dialog > > xscreensaver-1:4.24-2 > --------------------- > * Fri Mar 24 2006 Ray Strode - 1:4.24-2 > - add patch from jwz to reap zombie processes (bug 185833) > > xterm-211-4.FC6 > --------------- > * Wed Mar 29 2006 Jason Vas Dias - 211-4 > - fix bug 186935: cursor GCs must be freed with XtReleaseGC I know the fedora-release/repo stuff doesn't matter, but what about the other errors I'm seeing today's update? Updating : libgcj ################ [ 6/100]warning: /usr/lib/security/libgcj.security created as /usr/lib/security/libgcj.security.rpmnew Updating : selinux-policy-strict ##################### [ 25/100] libsepol.scope_copy_callback: authlogin: Duplicate declaration in module: type/attribute system_chkpwd_t libsemanage.semanage_link_sandbox: Link packages failed semodule: Failed! Updating : fedora-release [ 26/100]warning: /etc/yum.repos.d/fedora-core.repo created as /etc/yum.repos.d/fedora-core.repo.rpmnew Updating : fedora-release [ 26/100]warning: /etc/yum.repos.d/fedora-development.repo created as /etc/yum.repos.d/fedora-development.repo.rpmnew Updating : fedora-release [ 26/100]warning: /etc/yum.repos.d/fedora-extras-development.repo created as /etc/yum.repos.d/fedora-extras-development.repo.rpmnew Updating : fedora-release [ 26/100]warning: /etc/yum.repos.d/fedora-extras.repo created as /etc/yum.repos.d/fedora-extras.repo.rpmnew Updating : fedora-release [ 26/100]warning: /etc/yum.repos.d/fedora-updates-testing.repo created as /etc/yum.repos.d/fedora-updates-testing.repo.rpmnew Updating : fedora-release [ 26/100]warning: /etc/yum.repos.d/fedora-updates.repo created as /etc/yum.repos.d/fedora-updates.repo.rpmnew Updating : fedora-release ##################### [ 26/100] Updating : selinux-policy-targeted ##################### [ 30/100] /usr/sbin/load_policy: Can't load policy: Invalid argument libsemanage.semanage_reload_policy: load_policy returned error code 2. /usr/sbin/load_policy: Can't load policy: Invalid argument libsemanage.semanage_reload_policy: load_policy returned error code 2. semodule: Failed! /sbin/restorecon reset /usr/bin/hidd context system_u:object_r:bluetooth_exec_t->system_u:object_r:bin_t Updating : openoffice.org-base ##################### [ 31/100] -------------- next part -------------- An HTML attachment was scrubbed... URL: From justin.conover at gmail.com Thu Mar 30 17:52:58 2006 From: justin.conover at gmail.com (Justin Conover) Date: Thu, 30 Mar 2006 11:52:58 -0600 Subject: SELinux overview on line. In-Reply-To: <442A9F79.6010309@redhat.com> References: <442A9F79.6010309@redhat.com> Message-ID: On 3/29/06, Daniel J Walsh wrote: > > http://www.redhat.com/v/swf/SELinux/ > > Dan > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Good overview, thanks. Any chance your going to move your selinux for dummies to the selinux wiki or some were that might stay more permanent in the future than your blog? -------------- next part -------------- An HTML attachment was scrubbed... URL: From florin at andrei.myip.org Thu Mar 30 18:02:02 2006 From: florin at andrei.myip.org (Florin Andrei) Date: Thu, 30 Mar 2006 10:02:02 -0800 Subject: SELinux overview on line. In-Reply-To: <442A9F79.6010309@redhat.com> References: <442A9F79.6010309@redhat.com> Message-ID: <1143741722.2413.12.camel@rivendell.home.local> On Wed, 2006-03-29 at 09:53 -0500, Daniel J Walsh wrote: > http://www.redhat.com/v/swf/SELinux/ That's a very nice high-level introduction to SELinux. I sent it to several people who might be interested. Thanks! -- Florin Andrei http://florin.myip.org/ From justin.conover at gmail.com Thu Mar 30 18:04:10 2006 From: justin.conover at gmail.com (Justin Conover) Date: Thu, 30 Mar 2006 12:04:10 -0600 Subject: SELinux overview on line. In-Reply-To: References: <442A9F79.6010309@redhat.com> Message-ID: On 3/30/06, Justin Conover wrote: > > > > On 3/29/06, Daniel J Walsh wrote: > > > > http://www.redhat.com/v/swf/SELinux/ > > > > Dan > > > > -- > > fedora-selinux-list mailing list > > fedora-selinux-list at redhat.com > > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > > > > > Good overview, thanks. > > Any chance your going to move your selinux for dummies to the selinux wiki > or some were that might stay more permanent in the future than your blog? > Ignore the last part ;-) http://fedoraproject.org/wiki/SELinux/Dummies -------------- next part -------------- An HTML attachment was scrubbed... URL: From gajownik at fedora.pl Thu Mar 30 18:44:19 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 30 Mar 2006 20:44:19 +0200 Subject: Empty trash in Gnome Message-ID: <442C2703.3090208@fedora.pl> Hi! My friend noticed that with SELinux in enforcing mode ~/.Trash is full of the files but he cannot remove them -- clicking on trash icon placed on the desktop shows empty directory. I reproduced this bug on my machine (FC5, selinux-policy-targeted-2.2.25-2.fc5, Gnome 2.14) and found this avc message: Mar 30 19:19:47 X kernel: audit(1143739187.507:65): avc: denied { getattr } for pid=1810 comm="hald" name="/" dev=hda6 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:home_root_t:s0 tclass=dir Using audit2allow I created kosz.pp module and this resolved the problem (you need to reboot or restart haldaemon service). Here's the content of te file: [root at X ~]# cat kosz.te module kosz 1.0; require { role object_r; role system_r; class dir getattr; type hald_t; type home_root_t; }; allow hald_t home_root_t:dir getattr; [root at X ~]# Maybe default policy should be fixed? Thanks, Dawid -- ^_* From sds at tycho.nsa.gov Thu Mar 30 18:54:31 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 30 Mar 2006 13:54:31 -0500 Subject: Empty trash in Gnome In-Reply-To: <442C2703.3090208@fedora.pl> References: <442C2703.3090208@fedora.pl> Message-ID: <1143744871.24555.251.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-03-30 at 20:44 +0200, Dawid Gajownik wrote: > Hi! > My friend noticed that with SELinux in enforcing mode ~/.Trash is full > of the files but he cannot remove them -- clicking on trash icon placed > on the desktop shows empty directory. > > I reproduced this bug on my machine (FC5, > selinux-policy-targeted-2.2.25-2.fc5, Gnome 2.14) and found this avc > message: > > Mar 30 19:19:47 X kernel: audit(1143739187.507:65): avc: denied { > getattr } for pid=1810 comm="hald" name="/" dev=hda6 ino=2 > scontext=system_u:system_r:hald_t:s0 > tcontext=system_u:object_r:home_root_t:s0 tclass=dir > > Using audit2allow I created kosz.pp module and this resolved the problem > (you need to reboot or restart haldaemon service). Here's the content of > te file: > > [root at X ~]# cat kosz.te > module kosz 1.0; > > require { > role object_r; > role system_r; > > class dir getattr; > > type hald_t; > type home_root_t; > }; > > > allow hald_t home_root_t:dir getattr; > [root at X ~]# > > Maybe default policy should be fixed? How does that help, as it would only allow hald to stat(2) /home, not to search it or descend to the user's home directory at all? Why is hald involved in looking at the user's trash directory (pardon my ignorance)? -- Stephen Smalley National Security Agency From gajownik at fedora.pl Thu Mar 30 19:10:06 2006 From: gajownik at fedora.pl (Dawid Gajownik) Date: Thu, 30 Mar 2006 21:10:06 +0200 Subject: Empty trash in Gnome In-Reply-To: <1143744871.24555.251.camel@moss-spartans.epoch.ncsc.mil> References: <442C2703.3090208@fedora.pl> <1143744871.24555.251.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <442C2D0E.3030509@fedora.pl> Dnia 03/30/2006 08:53 PM, U?ytkownik Stephen Smalley napisa?: > How does that help, as it would only allow hald to stat(2) /home, not to > search it or descend to the user's home directory at all? Why is hald > involved in looking at the user's trash directory (pardon my ignorance)? Well, I don't know :) I'm a KDE user and I know nothing about Gnome internals. This link gave me some tips ? http://bugzilla.gnome.org/show_bug.cgi?id=171073 (search for hal). ~/.gnome/gnome-vfs/.trash_entry_cache is not updated correctly without updated SELinux policy. Regards, Dawid -- ^_* From sds at tycho.nsa.gov Thu Mar 30 19:18:59 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 30 Mar 2006 14:18:59 -0500 Subject: Empty trash in Gnome In-Reply-To: <442C2D0E.3030509@fedora.pl> References: <442C2703.3090208@fedora.pl> <1143744871.24555.251.camel@moss-spartans.epoch.ncsc.mil> <442C2D0E.3030509@fedora.pl> Message-ID: <1143746339.24555.259.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-03-30 at 21:10 +0200, Dawid Gajownik wrote: > Well, I don't know :) I'm a KDE user and I know nothing about Gnome > internals. This link gave me some tips ? > http://bugzilla.gnome.org/show_bug.cgi?id=171073 (search for hal). > > ~/.gnome/gnome-vfs/.trash_entry_cache is not updated correctly without > updated SELinux policy. Ok, per that bugzilla, nautilus asks hald for the set of mounted volumes, so that explains why hald just wants to stat /home as an existence test. So hald actually needs getattr to all mounted directories. -- Stephen Smalley National Security Agency From tibbs at math.uh.edu Thu Mar 30 19:42:52 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 30 Mar 2006 13:42:52 -0600 Subject: FC5 LDAP issues Message-ID: I've noticed that the behavior of my FC5 system differs dramatically depending on whether nscd is running. User info is stored in LDAP, and if nscd is running then applications talk to it. But if it's not running then the applications (or libc, at least) talk to the network themselves. This gets denied by selinux and things break. Most notably, the system won't even boot, because dbus just hangs forever spewing AVC messages to the console. So I wonder if the intention is to make nscd mandatory, or if failures due to a lack of nscd are considered problematic. I have nothing against nscd, but I don't generally turn it on until after the system boots and has time to pull down configuration information so that encrypted ldap works. Obviously I'll be reworking my installation scripts to work around this. - J< From dwalsh at redhat.com Thu Mar 30 19:51:11 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Mar 2006 14:51:11 -0500 Subject: AVC Decision Tree. Message-ID: <442C36AF.4090001@redhat.com> http://fedoraproject.org/wiki/SELinux/Troubleshooting/AVCDecisions#preview Trying to build a analysys tool to be able to translate avc messages into possible boolean/file_context solutions. The idea is that we can look at the AVC messages that are generated and figure out what the servers were trying to do. Then we can give some advise to the administrator on the corrective measures. So what we are looking for are expected code paths where there is a file context of boolean available. Additional suggestions are welcome. Dan From sds at tycho.nsa.gov Thu Mar 30 19:58:35 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 30 Mar 2006 14:58:35 -0500 Subject: FC5 LDAP issues In-Reply-To: References: Message-ID: <1143748715.24555.269.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-03-30 at 13:42 -0600, Jason L Tibbitts III wrote: > I've noticed that the behavior of my FC5 system differs dramatically > depending on whether nscd is running. User info is stored in LDAP, > and if nscd is running then applications talk to it. But if it's not > running then the applications (or libc, at least) talk to the network > themselves. This gets denied by selinux and things break. Most > notably, the system won't even boot, because dbus just hangs forever > spewing AVC messages to the console. > > So I wonder if the intention is to make nscd mandatory, or if failures > due to a lack of nscd are considered problematic. I have nothing > against nscd, but I don't generally turn it on until after the system > boots and has time to pull down configuration information so that > encrypted ldap works. Obviously I'll be reworking my installation > scripts to work around this. Does 'setsebool -P allow_ypbind=1' help? Same issue applies for NIS (w/o nscd), and that boolean is intended to allow necessary network access. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Thu Mar 30 20:00:13 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Mar 2006 15:00:13 -0500 Subject: Need testers for Modules policicy on RHEL4 In-Reply-To: <80d7e4090603291544m3096f484he2c4552cd6ec66a8@mail.gmail.com> References: <442B182D.9060104@redhat.com> <80d7e4090603291544m3096f484he2c4552cd6ec66a8@mail.gmail.com> Message-ID: <442C38CD.2000305@redhat.com> Stephen J. Smoogen wrote: > On 3/29/06, Daniel J Walsh wrote: > >> I have back ported the entire selinux tool chain to RHEL4. I have also >> attempted to create a modular policy to match RHEL4 policy as closely as >> possible. >> >> These packages are out on >> >> ftp://people.redhat.com/dwalsh/SELinux/RHEL4_MODULAR >> >> If anyone wants to play with these and do some testing that would be great. >> > > Cool. I realize there is no promise but I will try them on a test box. > What should I look for in a test plan? Also what is the difference > between selinux-policy-2.2.28-1.rhel4.noarch.rpm and > selinux-policy-targeted-2.2.28-1.rhel4.noarch.rpm? > > Look for regressions. Want to make sure RHEL4 works the same under both. The new policy has some added allows but should not have any ones missing. There are some types that have been eliminated but they were not used. > >> There is no commitment from Red Hat to ever ship this. But if it is >> ever going to ship, >> we need to find problems with it now. >> >> So if you have a spare RHEL4 box and want to play with modular policy, >> this is your chance. >> >> Thanks, >> >> >> Dan >> >> -- >> fedora-selinux-list mailing list >> fedora-selinux-list at redhat.com >> https://www.redhat.com/mailman/listinfo/fedora-selinux-list >> >> > > > -- > Stephen J Smoogen. > CSIRT/Linux System Administrator > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From tibbs at math.uh.edu Thu Mar 30 20:05:58 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 30 Mar 2006 14:05:58 -0600 Subject: FC5 LDAP issues In-Reply-To: (Jason L. Tibbitts, III's message of "Thu, 30 Mar 2006 13:42:52 -0600") References: Message-ID: I realize that the issue is more complicated, because even with nscd turned on, dbus-daemon still fails to start. It's looking in /etc/pki: Mar 30 13:50:33 util10 kernel: audit(1143748233.484:304): avc: denied { search } for pid=1711 comm="dbus-daemon" name="pki" dev=dm-0 ino=163878 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=dir I wonder if I have broken something. - J< From dwalsh at redhat.com Thu Mar 30 20:13:46 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Mar 2006 15:13:46 -0500 Subject: FC5 LDAP issues In-Reply-To: References: Message-ID: <442C3BFA.7060206@redhat.com> Jason L Tibbitts III wrote: > I realize that the issue is more complicated, because even with nscd > turned on, dbus-daemon still fails to start. It's looking in > /etc/pki: > > Mar 30 13:50:33 util10 kernel: audit(1143748233.484:304): avc: denied { search } for pid=1711 comm="dbus-daemon" name="pki" dev=dm-0 ino=163878 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=dir > > I wonder if I have broken something. > > - J< > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > Can you setenforce now and then start it up, please collect all of the avc messages. From sds at tycho.nsa.gov Thu Mar 30 20:23:27 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Thu, 30 Mar 2006 15:23:27 -0500 Subject: FC5 LDAP issues In-Reply-To: References: Message-ID: <1143750207.24555.286.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-03-30 at 14:05 -0600, Jason L Tibbitts III wrote: > I realize that the issue is more complicated, because even with nscd > turned on, dbus-daemon still fails to start. It's looking in > /etc/pki: > > Mar 30 13:50:33 util10 kernel: audit(1143748233.484:304): avc: denied { search } for pid=1711 comm="dbus-daemon" name="pki" dev=dm-0 ino=163878 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=dir > > I wonder if I have broken something. Ah, so your dbus config refers to files in /etc/pki? Likely not allowed by the current policy. grep -r pki /etc/dbus-1 -- Stephen Smalley National Security Agency From tibbs at math.uh.edu Thu Mar 30 20:24:28 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 30 Mar 2006 14:24:28 -0600 Subject: FC5 LDAP issues In-Reply-To: <442C3BFA.7060206@redhat.com> (Daniel J. Walsh's message of "Thu, 30 Mar 2006 15:13:46 -0500") References: <442C3BFA.7060206@redhat.com> Message-ID: >>>>> "DJW" == Daniel J Walsh writes: DJW> Can you setenforce now and then start it up, please collect all DJW> of the avc messages. Since I can't even boot in enforcing mode, I'm running in permissive mode and just after boot I have 24 denials. Many of these are probably normal but several are looking in /etc/pki for various certs. These are probably related to LDAP; /etc/ldap.conf requires encryption so anything that needs to look at users or groups before nscd starts will need to see the certs. > cat /etc/ldap.conf base dc=blah uri ldaps://xxxx ldaps://yyyy ldaps://zzzz bind_timelimit 3 idle_timelimit 3600 tls_checkpeer yes tls_cacertfile /etc/pki/cacert.pem > sestatus SELinux status: enabled SELinuxfs mount: /selinux Current mode: permissive Mode from config file: permissive Policy version: 20 Policy from config file: targeted > dmesg|grep avc audit(1143749462.567:2): avc: denied { search } for pid=659 comm="pam_console_app" name="var" dev=dm-0 ino=98305 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir audit(1143749475.708:3): avc: denied { read } for pid=1261 comm="fsck" name="blkid.tab" dev=dm-0 ino=167310 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file audit(1143749475.708:4): avc: denied { getattr } for pid=1261 comm="fsck" name="blkid.tab" dev=dm-0 ino=167310 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file audit(1143749475.772:5): avc: denied { read } for pid=1263 comm="fsck.ext3" name="mtab" dev=dm-0 ino=167311 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file audit(1143749475.772:6): avc: denied { getattr } for pid=1263 comm="fsck.ext3" name="mtab" dev=dm-0 ino=167311 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file audit(1143749476.672:7): avc: denied { write } for pid=1279 comm="mount" name="blkid.tab" dev=dm-0 ino=167310 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file audit(1143749476.672:8): avc: denied { unlink } for pid=1279 comm="mount" name="blkid.tab.old" dev=dm-0 ino=165330 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file audit(1143749476.672:9): avc: denied { link } for pid=1279 comm="mount" name="blkid.tab" dev=dm-0 ino=167310 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file audit(1143749708.498:10): avc: denied { search } for pid=1719 comm="dbus-daemon" name="pki" dev=dm-0 ino=163878 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=dir audit(1143749708.498:11): avc: denied { read } for pid=1719 comm="dbus-daemon" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file audit(1143749708.498:12): avc: denied { getattr } for pid=1719 comm="dbus-daemon" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file audit(1143749708.498:13): avc: denied { read } for pid=1719 comm="dbus-daemon" name="cert.pem" dev=dm-0 ino=164178 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=lnk_file audit(1143749710.051:14): avc: denied { mounton } for pid=1773 comm="mount" name="mail" dev=dm-4 ino=589827 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir audit(1143749711.663:15): avc: denied { read } for pid=1950 comm="automount" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file audit(1143749711.663:16): avc: denied { getattr } for pid=1950 comm="automount" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file audit(1143749711.663:17): avc: denied { read } for pid=1950 comm="automount" name="cert.pem" dev=dm-0 ino=164178 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=lnk_file audit(1143749720.792:18): avc: denied { getattr } for pid=2240 comm="hald" name="/" dev=dm-1 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir audit(1143749720.792:19): avc: denied { search } for pid=2240 comm="hald" name="spool" dev=dm-4 ino=589825 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir audit(1143749801.841:20): avc: denied { write } for pid=2352 comm="mount" name="socket" dev=dm-4 ino=917527 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=sock_file audit(1143749801.841:21): avc: denied { connectto } for pid=2352 comm="mount" name="socket" scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:nscd_t:s0 tclass=unix_stream_socket audit(1143749801.841:22): avc: denied { use } for pid=2352 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:nscd_t:s0 tclass=fd audit(1143749801.841:23): avc: denied { read } for pid=2352 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=file audit(1143749801.841:24): avc: denied { getattr } for pid=2352 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=file audit(1143749801.869:25): avc: denied { getattr } for pid=2240 comm="hald" name="/" dev=dm-1 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir - J< From tibbs at math.uh.edu Thu Mar 30 20:28:14 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 30 Mar 2006 14:28:14 -0600 Subject: FC5 LDAP issues In-Reply-To: <1143750207.24555.286.camel@moss-spartans.epoch.ncsc.mil> (Stephen Smalley's message of "Thu, 30 Mar 2006 15:23:27 -0500") References: <1143750207.24555.286.camel@moss-spartans.epoch.ncsc.mil> Message-ID: >>>>> "SS" == Stephen Smalley writes: SS> Ah, so your dbus config refers to files in /etc/pki? Likely not SS> allowed by the current policy. I haven't touched the dbus configuration; it is 100% stock. SS> grep -r pki /etc/dbus-1 It finds nothing. - J< From dwalsh at redhat.com Thu Mar 30 20:28:29 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Mar 2006 15:28:29 -0500 Subject: FC5 LDAP issues In-Reply-To: References: <442C3BFA.7060206@redhat.com> Message-ID: <442C3F6D.3070901@redhat.com> Jason L Tibbitts III wrote: >>>>>> "DJW" == Daniel J Walsh writes: >>>>>> > > DJW> Can you setenforce now and then start it up, please collect all > DJW> of the avc messages. > > Since I can't even boot in enforcing mode, I'm running in permissive > mode and just after boot I have 24 denials. Many of these are > probably normal but several are looking in /etc/pki for various > certs. These are probably related to LDAP; /etc/ldap.conf requires > encryption so anything that needs to look at users or groups before > nscd starts will need to see the certs. > > >> cat /etc/ldap.conf >> > base dc=blah > uri ldaps://xxxx ldaps://yyyy ldaps://zzzz > bind_timelimit 3 > idle_timelimit 3600 > tls_checkpeer yes > tls_cacertfile /etc/pki/cacert.pem > > >> sestatus >> > SELinux status: enabled > SELinuxfs mount: /selinux > Current mode: permissive > Mode from config file: permissive > Policy version: 20 > Policy from config file: targeted > > >> dmesg|grep avc >> > audit(1143749462.567:2): avc: denied { search } for pid=659 comm="pam_console_app" name="var" dev=dm-0 ino=98305 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir > audit(1143749475.708:3): avc: denied { read } for pid=1261 comm="fsck" name="blkid.tab" dev=dm-0 ino=167310 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > audit(1143749475.708:4): avc: denied { getattr } for pid=1261 comm="fsck" name="blkid.tab" dev=dm-0 ino=167310 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > audit(1143749475.772:5): avc: denied { read } for pid=1263 comm="fsck.ext3" name="mtab" dev=dm-0 ino=167311 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > audit(1143749475.772:6): avc: denied { getattr } for pid=1263 comm="fsck.ext3" name="mtab" dev=dm-0 ino=167311 scontext=system_u:system_r:fsadm_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > audit(1143749476.672:7): avc: denied { write } for pid=1279 comm="mount" name="blkid.tab" dev=dm-0 ino=167310 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > audit(1143749476.672:8): avc: denied { unlink } for pid=1279 comm="mount" name="blkid.tab.old" dev=dm-0 ino=165330 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > audit(1143749476.672:9): avc: denied { link } for pid=1279 comm="mount" name="blkid.tab" dev=dm-0 ino=167310 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:file_t:s0 tclass=file > audit(1143749708.498:10): avc: denied { search } for pid=1719 comm="dbus-daemon" name="pki" dev=dm-0 ino=163878 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=dir > audit(1143749708.498:11): avc: denied { read } for pid=1719 comm="dbus-daemon" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > audit(1143749708.498:12): avc: denied { getattr } for pid=1719 comm="dbus-daemon" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > audit(1143749708.498:13): avc: denied { read } for pid=1719 comm="dbus-daemon" name="cert.pem" dev=dm-0 ino=164178 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=lnk_file > audit(1143749710.051:14): avc: denied { mounton } for pid=1773 comm="mount" name="mail" dev=dm-4 ino=589827 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir > audit(1143749711.663:15): avc: denied { read } for pid=1950 comm="automount" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > audit(1143749711.663:16): avc: denied { getattr } for pid=1950 comm="automount" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > audit(1143749711.663:17): avc: denied { read } for pid=1950 comm="automount" name="cert.pem" dev=dm-0 ino=164178 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=lnk_file > audit(1143749720.792:18): avc: denied { getattr } for pid=2240 comm="hald" name="/" dev=dm-1 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir > audit(1143749720.792:19): avc: denied { search } for pid=2240 comm="hald" name="spool" dev=dm-4 ino=589825 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir > audit(1143749801.841:20): avc: denied { write } for pid=2352 comm="mount" name="socket" dev=dm-4 ino=917527 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=sock_file > audit(1143749801.841:21): avc: denied { connectto } for pid=2352 comm="mount" name="socket" scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:nscd_t:s0 tclass=unix_stream_socket > audit(1143749801.841:22): avc: denied { use } for pid=2352 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:nscd_t:s0 tclass=fd > audit(1143749801.841:23): avc: denied { read } for pid=2352 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=file > audit(1143749801.841:24): avc: denied { getattr } for pid=2352 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=file > audit(1143749801.869:25): avc: denied { getattr } for pid=2240 comm="hald" name="/" dev=dm-1 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir > > - J< > Looks like you have a labeling problem. Your var partition looks like it is labeled file_t. So if you relabel things might clear up touch /.autorelabel reboot From dwalsh at redhat.com Thu Mar 30 20:31:40 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Mar 2006 15:31:40 -0500 Subject: Targeted strategy guidance needed In-Reply-To: <00b501c65351$628b23a0$8103a8c0@rokswdev.local> References: <00b501c65351$628b23a0$8103a8c0@rokswdev.local> Message-ID: <442C402C.40408@redhat.com> Gary Kopp wrote: > Would someone on this list be able to take a moment to give me a sanity > check and tell me if I'm on the right track? I'm configuring a RHEL4 server > to be an Internet-facing web/mail server. It will run httpd, postfix, and > courier-imap. Most application logic (including any requirement for SQL > access) will live on other servers that I'm not concerned about in the > context of SELinux, but this web server will probably have to run one PHP > application (Blog:CMS). I desire this web server to be as secure as > possible. > > I have not yet mastered the intricacies of SELinux (but I'm working on > that), and I thought that by using Red Hat's targeted SELinux policy I'd > have a head start. I also thought this would leverage my investment in the > Red Hat Enterprise Linux support contract, being able to turn to Red Hat > support for help. I have since found out that my support agreement (SLA) > does not cover any SELinux issues arising from a modified targeted policy. > > And right out of the chute I see that I can't live with the targeted policy > as delivered, and need to tweak it. For example, this server uses syslog-ng, > and the targeted policy is already complaining. Red Hat's SELinux Guide > offers instructions on how to add rules to local.te to get around minor > issues like this, and I'm willing to do that, but then I'll have no support > from Red Hat directly. I also anticipate that my httpd config may require > some policy tweaks (e.g., I'm thinking of putting Apache logs in a > non-standard location). > > Next, the delivered targeted policy doesn't constrain postfix (it seems to > reference postfix, but then aliases it to unconfined). Again, the Guide > suggests I could write new policy specifically for something like postfix, > in essence extending the targeted policy. Interestingly, I see that the > gentoo project has a whole bunch of SELinux policies available, including > one for postfix. A side question I have is: does it make sense to adapt/use > the policies available in the gentoo project to extend the targeted policy > for new processes, or is that a bad idea? > > I'm assuming that the RHEL targeted policy and the FC policy, the subject of > this mailing list, are one and the same, and therefore I'm not out of line > coming to this list. Am I correct? As a RHEL user rather than a FC user > can I still use this list as a resource? > > OK, here's my fundamental question: Given what I'm trying to achieve, is my > proper approach to start tweaking and extending the delivered targeted > policy? Is that commonly done, or should I be looking at some other strategy > to meet my needs? > > I'll be grateful for any advice anyone would like to offer. TIA > > Yes you can do that and we will help you. In order to satisfy your support contract, I believe you would need to recreate a problem with the standard selinux policy. Dan > --Gary Kopp > > -- > fedora-selinux-list mailing list > fedora-selinux-list at redhat.com > https://www.redhat.com/mailman/listinfo/fedora-selinux-list > From dwalsh at redhat.com Thu Mar 30 20:32:17 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Mar 2006 15:32:17 -0500 Subject: ReiserFS chicken and egg In-Reply-To: <1143726115.24555.143.camel@moss-spartans.epoch.ncsc.mil> References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> <1143635045.20394.5.camel@moss-spartans.epoch.ncsc.mil> <1143636184.20394.24.camel@moss-spartans.epoch.ncsc.mil> <1143726115.24555.143.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <442C4051.9060601@redhat.com> Stephen Smalley wrote: > On Wed, 2006-03-29 at 13:34 -0600, Ian Pilcher wrote: > >> Sorry about the delay...jury duty. >> >> Just tried again to be sure: >> >> mkfs.reiserfs /dev/md9 >> >> /etc/fstab contains: >> >> /dev/md9 /mnt/tmp reiserfs context=system_u:object_r:file_t:s0 0 2 >> >> Rebooted and the mount failed. dmesg | grep md9 shows: >> >> audit(1143660461.416:15): avc: denied { search } for pid=1714 >> comm="mount" name="/" dev=md9 ino=2 >> scontext=system_u:system_r:mount_t:s0 >> tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir >> ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create >> .reiserfs_priv. Failing mount. >> >> It doesn't look like the context option had any affect at all. >> > > I think we are encountering the denial before we reach the processing of > the context option. The setup of the superblock security data and the > root directory security data happens upon security_sb_kern_mount, but > this is called after the filesystem returns from its get_sb method. > Unfortunately, reiserfs apparently tries to access the xattr directory > during get_sb, so there is an attempted lookup before SELinux has > initialized the security state on the root directory, and we get a > denial on unlabeled_t. I guess you need to allow mount_t > unlabeled_t:dir search; to workaround it. > > Should we allow this in policy? From tibbs at math.uh.edu Thu Mar 30 20:44:14 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 30 Mar 2006 14:44:14 -0600 Subject: FC5 LDAP issues In-Reply-To: <442C3F6D.3070901@redhat.com> (Daniel J. Walsh's message of "Thu, 30 Mar 2006 15:28:29 -0500") References: <442C3BFA.7060206@redhat.com> <442C3F6D.3070901@redhat.com> Message-ID: >>>>> "DJW" == Daniel J Walsh writes: DJW> Looks like you have a labeling problem. The system relabeled itself as part of the boot. But I've forced another relabel and there are eight fewer messages: audit(1143750802.325:2): avc: denied { search } for pid=636 comm="pam_console_app" name="var" dev=dm-0 ino=98305 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir audit(1143751052.509:3): avc: denied { search } for pid=1723 comm="dbus-daemon" name="pki" dev=dm-0 ino=163878 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=dir audit(1143751052.509:4): avc: denied { read } for pid=1723 comm="dbus-daemon" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file audit(1143751052.517:5): avc: denied { getattr } for pid=1723 comm="dbus-daemon" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file audit(1143751052.521:6): avc: denied { read } for pid=1723 comm="dbus-daemon" name="cert.pem" dev=dm-0 ino=164178 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=lnk_file audit(1143751053.465:7): avc: denied { mounton } for pid=1777 comm="mount" name="mail" dev=dm-4 ino=589827 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir audit(1143751055.021:8): avc: denied { read } for pid=1954 comm="automount" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file audit(1143751055.021:9): avc: denied { getattr } for pid=1954 comm="automount" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file audit(1143751055.025:10): avc: denied { read } for pid=1954 comm="automount" name="cert.pem" dev=dm-0 ino=164178 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=lnk_file audit(1143751064.226:11): avc: denied { getattr } for pid=2244 comm="hald" name="/" dev=dm-1 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir audit(1143751064.230:12): avc: denied { search } for pid=2244 comm="hald" name="spool" dev=dm-4 ino=589825 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir audit(1143751066.602:13): avc: denied { write } for pid=2341 comm="mount" name="socket" dev=dm-4 ino=917527 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=sock_file audit(1143751066.602:14): avc: denied { connectto } for pid=2341 comm="mount" name="socket" scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:nscd_t:s0 tclass=unix_stream_socket audit(1143751066.606:15): avc: denied { use } for pid=2341 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:nscd_t:s0 tclass=fd audit(1143751066.606:16): avc: denied { read } for pid=2341 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=file audit(1143751066.606:17): avc: denied { getattr } for pid=2341 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=file I had been running with selinux disabled for some time, but when I enabled it earlier today the system relabeled itself and then it did so again when I switched to permissive. Does the boot-time relabel log the changes it makes? I'd like to see why the third relabel changed things. In any case, there are still the cert failures which will keep the machine from booting. - J< From cpebenito at tresys.com Thu Mar 30 20:59:16 2006 From: cpebenito at tresys.com (Christopher J. PeBenito) Date: Thu, 30 Mar 2006 15:59:16 -0500 Subject: Need testers for Modules policicy on RHEL4 In-Reply-To: <442C38CD.2000305@redhat.com> References: <442B182D.9060104@redhat.com> <80d7e4090603291544m3096f484he2c4552cd6ec66a8@mail.gmail.com> <442C38CD.2000305@redhat.com> Message-ID: <1143752356.13732.63.camel@sgc> On Thu, 2006-03-30 at 15:00 -0500, Daniel J Walsh wrote: > Stephen J. Smoogen wrote: > > On 3/29/06, Daniel J Walsh wrote: > >> I have back ported the entire selinux tool chain to RHEL4. I have also > >> attempted to create a modular policy to match RHEL4 policy as closely as > >> possible. > >> > >> These packages are out on > >> > >> ftp://people.redhat.com/dwalsh/SELinux/RHEL4_MODULAR > >> > >> If anyone wants to play with these and do some testing that would be great. > > > > Cool. I realize there is no promise but I will try them on a test box. > > What should I look for in a test plan? Also what is the difference > > between selinux-policy-2.2.28-1.rhel4.noarch.rpm and > > selinux-policy-targeted-2.2.28-1.rhel4.noarch.rpm? > > > > > Look for regressions. Want to make sure RHEL4 works the same under > both. The new policy has some added allows but should not have any ones > missing. There are some types that have been eliminated but they were > not used. One known thing would be the missing su(do)+pam_login rules. I plan on making a rhel4 distro tunable (which infers the redhat tunable too), to handle things that are in RHEL4, but no longer in newer Red Hat releases. -- Chris PeBenito Tresys Technology, LLC (410) 290-1411 x150 From rmy at tigress.co.uk Thu Mar 30 21:03:50 2006 From: rmy at tigress.co.uk (Ron Yorston) Date: Thu, 30 Mar 2006 22:03:50 +0100 (BST) Subject: logwatch does not show disk usage of partitions mounted in /mnt Message-ID: <200603302103.k2UL3oRv022427@tiffany.internal.tigress.co.uk> Daniel J Walsh wrote: >Well I am a developer of SELinux policy. The policy I put out yesterday >will dontaudit this, but now I am thinking it should be allowed. Please, allow it. What was the rationale for preventing logwatch showing disk usage of partitions mounted in /mnt anyway? Ron From dwalsh at redhat.com Thu Mar 30 22:18:43 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Mar 2006 17:18:43 -0500 Subject: FC5 LDAP issues In-Reply-To: References: <442C3BFA.7060206@redhat.com> <442C3F6D.3070901@redhat.com> Message-ID: <442C5943.3010802@redhat.com> Jason L Tibbitts III wrote: >>>>>> "DJW" == Daniel J Walsh writes: >>>>>> > > DJW> Looks like you have a labeling problem. > > The system relabeled itself as part of the boot. But I've forced > another relabel and there are eight fewer messages: > > audit(1143750802.325:2): avc: denied { search } for pid=636 comm="pam_console_app" name="var" dev=dm-0 ino=98305 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir > audit(1143751052.509:3): avc: denied { search } for pid=1723 comm="dbus-daemon" name="pki" dev=dm-0 ino=163878 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=dir > audit(1143751052.509:4): avc: denied { read } for pid=1723 comm="dbus-daemon" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > audit(1143751052.517:5): avc: denied { getattr } for pid=1723 comm="dbus-daemon" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > audit(1143751052.521:6): avc: denied { read } for pid=1723 comm="dbus-daemon" name="cert.pem" dev=dm-0 ino=164178 scontext=system_u:system_r:system_dbusd_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=lnk_file > audit(1143751053.465:7): avc: denied { mounton } for pid=1777 comm="mount" name="mail" dev=dm-4 ino=589827 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:mail_spool_t:s0 tclass=dir > audit(1143751055.021:8): avc: denied { read } for pid=1954 comm="automount" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > audit(1143751055.021:9): avc: denied { getattr } for pid=1954 comm="automount" name="cacert.pem" dev=dm-0 ino=165663 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=file > audit(1143751055.025:10): avc: denied { read } for pid=1954 comm="automount" name="cert.pem" dev=dm-0 ino=164178 scontext=system_u:system_r:automount_t:s0 tcontext=system_u:object_r:cert_t:s0 tclass=lnk_file > audit(1143751064.226:11): avc: denied { getattr } for pid=2244 comm="hald" name="/" dev=dm-1 ino=2 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:default_t:s0 tclass=dir > audit(1143751064.230:12): avc: denied { search } for pid=2244 comm="hald" name="spool" dev=dm-4 ino=589825 scontext=system_u:system_r:hald_t:s0 tcontext=system_u:object_r:var_spool_t:s0 tclass=dir > audit(1143751066.602:13): avc: denied { write } for pid=2341 comm="mount" name="socket" dev=dm-4 ino=917527 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=sock_file > audit(1143751066.602:14): avc: denied { connectto } for pid=2341 comm="mount" name="socket" scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:nscd_t:s0 tclass=unix_stream_socket > audit(1143751066.606:15): avc: denied { use } for pid=2341 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:system_r:nscd_t:s0 tclass=fd > audit(1143751066.606:16): avc: denied { read } for pid=2341 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=file > audit(1143751066.606:17): avc: denied { getattr } for pid=2341 comm="mount" name="hosts" dev=dm-4 ino=622598 scontext=system_u:system_r:mount_t:s0 tcontext=system_u:object_r:nscd_var_run_t:s0 tclass=file > > I had been running with selinux disabled for some time, but when I > enabled it earlier today the system relabeled itself and then it did > so again when I switched to permissive. Does the boot-time relabel > log the changes it makes? I'd like to see why the third relabel > changed things. > > In any case, there are still the cert failures which will keep the > machine from booting. > > - J< > You can use audit2allow -l -M local -i /var/log/messages to generate a loadable module, and work around this problem. The question I have is why do dbus and automount want to read the certificate files? Dan From dwalsh at redhat.com Thu Mar 30 22:36:22 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Thu, 30 Mar 2006 17:36:22 -0500 Subject: FC5 LDAP issues In-Reply-To: <442C5943.3010802@redhat.com> References: <442C3BFA.7060206@redhat.com> <442C3F6D.3070901@redhat.com> <442C5943.3010802@redhat.com> Message-ID: <442C5D66.8010700@redhat.com> I have been informed that if you are running ldap-with-ssl you will need these permissions. So added to selinux-policy-2.2.28-3 Available in Rawhide tomorrow On ftp://people.redhat.com/dwalsh/SELinux/Fedora Now Will be back ported to FC5 soon. From tibbs at math.uh.edu Fri Mar 31 00:07:29 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Thu, 30 Mar 2006 18:07:29 -0600 Subject: FC5 LDAP issues In-Reply-To: <442C5D66.8010700@redhat.com> (Daniel J. Walsh's message of "Thu, 30 Mar 2006 17:36:22 -0500") References: <442C3BFA.7060206@redhat.com> <442C3F6D.3070901@redhat.com> <442C5943.3010802@redhat.com> <442C5D66.8010700@redhat.com> Message-ID: >>>>> "DJW" == Daniel J Walsh writes: DJW> I have been informed that if you are running ldap-with-ssl you DJW> will need these permissions. Cool, thanks. I'll pull the policy from CVS and try it out tomorrow. - J< From tscherf at redhat.com Fri Mar 31 09:44:25 2006 From: tscherf at redhat.com (Thorsten Scherf) Date: Fri, 31 Mar 2006 11:44:25 +0200 Subject: AVC Decision Tree. In-Reply-To: <442C36AF.4090001@redhat.com> References: <442C36AF.4090001@redhat.com> Message-ID: <1143798266.3145.12.camel@tiffy.tuxgeek.de> On Thu, 2006-03-30 at 14:51 -0500, Daniel J Walsh wrote: > http://fedoraproject.org/wiki/SELinux/Troubleshooting/AVCDecisions#preview > > Trying to build a analysys tool to be able to translate avc messages > into possible boolean/file_context solutions. > > The idea is that we can look at the AVC messages that are generated and > figure out what the servers were trying to do. Then we can give some > advise to the administrator on the corrective measures. So what we are > looking for are expected code paths where there is a file context of > boolean available. Usually if a AVC denied is fixed with a corresponding rule, the next AVC comes up in the log (allow getattr, after that ACV:denied read, and so on). Probably we don't want to annoy the administrator with several pop-ups coming up on his screen. What do you think about that? -- Thorsten Scherf, RHCE, RHCA, RHCSS Mobile: ++49 172 61 32 548 Red Hat GLS EMEA Fax: ++49 2064 470 564 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 191 bytes Desc: This is a digitally signed message part URL: From sds at tycho.nsa.gov Fri Mar 31 12:33:18 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 31 Mar 2006 07:33:18 -0500 Subject: FC5 LDAP issues In-Reply-To: <442C5D66.8010700@redhat.com> References: <442C3BFA.7060206@redhat.com> <442C3F6D.3070901@redhat.com> <442C5943.3010802@redhat.com> <442C5D66.8010700@redhat.com> Message-ID: <1143808398.24555.289.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-03-30 at 17:36 -0500, Daniel J Walsh wrote: > I have been informed that if you are running ldap-with-ssl you will need > these permissions. > > So added to selinux-policy-2.2.28-3 > > Available in Rawhide tomorrow > On ftp://people.redhat.com/dwalsh/SELinux/Fedora Now > > Will be back ported to FC5 soon. Is this under a boolean? Allowing such wide ranging access to the cert files is obviously not desirable in general... -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Mar 31 13:13:17 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 31 Mar 2006 08:13:17 -0500 Subject: Targeted strategy guidance needed In-Reply-To: <442C402C.40408@redhat.com> References: <00b501c65351$628b23a0$8103a8c0@rokswdev.local> <442C402C.40408@redhat.com> Message-ID: <1143810797.24555.296.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-03-30 at 15:31 -0500, Daniel J Walsh wrote: > > Next, the delivered targeted policy doesn't constrain postfix (it seems to > > reference postfix, but then aliases it to unconfined). Again, the Guide > > suggests I could write new policy specifically for something like postfix, > > in essence extending the targeted policy. Interestingly, I see that the > > gentoo project has a whole bunch of SELinux policies available, including > > one for postfix. A side question I have is: does it make sense to adapt/use > > the policies available in the gentoo project to extend the targeted policy > > for new processes, or is that a bad idea? Adapting policies from Gentoo to RHEL4 is unlikely to be fruitful due to divergence between their base policies, but there is already a postfix policy in the upstream example and/or reference policy, and that is included in Fedora Core 4 and later I believe. So you can use the postfix policy from Fedora instead, with some modification. -- Stephen Smalley National Security Agency From sds at tycho.nsa.gov Fri Mar 31 13:15:48 2006 From: sds at tycho.nsa.gov (Stephen Smalley) Date: Fri, 31 Mar 2006 08:15:48 -0500 Subject: ReiserFS chicken and egg In-Reply-To: <442C4051.9060601@redhat.com> References: <1143578731.3037.144.camel@moss-spartans.epoch.ncsc.mil> <1143635045.20394.5.camel@moss-spartans.epoch.ncsc.mil> <1143636184.20394.24.camel@moss-spartans.epoch.ncsc.mil> <1143726115.24555.143.camel@moss-spartans.epoch.ncsc.mil> <442C4051.9060601@redhat.com> Message-ID: <1143810948.24555.300.camel@moss-spartans.epoch.ncsc.mil> On Thu, 2006-03-30 at 15:32 -0500, Daniel J Walsh wrote: > Stephen Smalley wrote: > > On Wed, 2006-03-29 at 13:34 -0600, Ian Pilcher wrote: > > > >> Sorry about the delay...jury duty. > >> > >> Just tried again to be sure: > >> > >> mkfs.reiserfs /dev/md9 > >> > >> /etc/fstab contains: > >> > >> /dev/md9 /mnt/tmp reiserfs context=system_u:object_r:file_t:s0 0 2 > >> > >> Rebooted and the mount failed. dmesg | grep md9 shows: > >> > >> audit(1143660461.416:15): avc: denied { search } for pid=1714 > >> comm="mount" name="/" dev=md9 ino=2 > >> scontext=system_u:system_r:mount_t:s0 > >> tcontext=system_u:object_r:unlabeled_t:s0 tclass=dir > >> ReiserFS: md9: warning: xattrs/ACLs enabled and couldn't find/create > >> .reiserfs_priv. Failing mount. > >> > >> It doesn't look like the context option had any affect at all. > >> > > > > I think we are encountering the denial before we reach the processing of > > the context option. The setup of the superblock security data and the > > root directory security data happens upon security_sb_kern_mount, but > > this is called after the filesystem returns from its get_sb method. > > Unfortunately, reiserfs apparently tries to access the xattr directory > > during get_sb, so there is an attempted lookup before SELinux has > > initialized the security state on the root directory, and we get a > > denial on unlabeled_t. I guess you need to allow mount_t > > unlabeled_t:dir search; to workaround it. > > > > > Should we allow this in policy? Unclear - it can easily be added by a module on the end systems, and it is a definite corner case that is not usually required. -- Stephen Smalley National Security Agency From dwalsh at redhat.com Fri Mar 31 17:03:43 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 31 Mar 2006 12:03:43 -0500 Subject: AVC Decision Tree. In-Reply-To: <1143798266.3145.12.camel@tiffy.tuxgeek.de> References: <442C36AF.4090001@redhat.com> <1143798266.3145.12.camel@tiffy.tuxgeek.de> Message-ID: <442D60EF.1030303@redhat.com> Thorsten Scherf wrote: > On Thu, 2006-03-30 at 14:51 -0500, Daniel J Walsh wrote: > >> http://fedoraproject.org/wiki/SELinux/Troubleshooting/AVCDecisions#preview >> >> Trying to build a analysys tool to be able to translate avc messages >> into possible boolean/file_context solutions. >> >> The idea is that we can look at the AVC messages that are generated and >> figure out what the servers were trying to do. Then we can give some >> advise to the administrator on the corrective measures. So what we are >> looking for are expected code paths where there is a file context of >> boolean available. >> > > Usually if a AVC denied is fixed with a corresponding rule, the next AVC > comes up in the log (allow getattr, after that ACV:denied read, and so > on). Probably we don't want to annoy the administrator with several > pop-ups coming up on his screen. > > What do you think about that? > > Yes the idea would be to continue gathering all of the AVC's while the app is running. I do not believe they will be able close the window faster than the AVC MEssages. The app should have a disable button built in so that if their is a real labeling problem, it will not keep popping up. So we will have to watch our usability. :^) But hopefully there will not be a lot of AVC messages :^) Dan From dwalsh at redhat.com Fri Mar 31 17:08:04 2006 From: dwalsh at redhat.com (Daniel J Walsh) Date: Fri, 31 Mar 2006 12:08:04 -0500 Subject: FC5 LDAP issues In-Reply-To: <1143808398.24555.289.camel@moss-spartans.epoch.ncsc.mil> References: <442C3BFA.7060206@redhat.com> <442C3F6D.3070901@redhat.com> <442C5943.3010802@redhat.com> <442C5D66.8010700@redhat.com> <1143808398.24555.289.camel@moss-spartans.epoch.ncsc.mil> Message-ID: <442D61F4.2080606@redhat.com> Stephen Smalley wrote: > On Thu, 2006-03-30 at 17:36 -0500, Daniel J Walsh wrote: > >> I have been informed that if you are running ldap-with-ssl you will need >> these permissions. >> >> So added to selinux-policy-2.2.28-3 >> >> Available in Rawhide tomorrow >> On ftp://people.redhat.com/dwalsh/SELinux/Fedora Now >> >> Will be back ported to FC5 soon. >> > > Is this under a boolean? Allowing such wide ranging access to the cert > files is obviously not desirable in general... > > Which should I put under a boolean? grep -r miscfiles_read_cert . ./modules/apps/evolution.if: miscfiles_read_certs($1_evolution_server_t) ./modules/system/authlogin.if: miscfiles_read_certs($1_chkpwd_t) ./modules/system/authlogin.if: miscfiles_read_certs($1) ./modules/system/init.te:miscfiles_read_certs(initrc_t) ./modules/system/miscfiles.if:interface(`miscfiles_read_certs',` ./modules/admin/certwatch.te:miscfiles_read_certs(certwatch_t) ./modules/services/dbus.te:miscfiles_read_certs(system_dbusd_t) ./modules/services/cyrus.te:miscfiles_read_certs(cyrus_t) ./modules/services/fetchmail.te:miscfiles_read_certs(fetchmail_t) ./modules/services/dovecot.te:miscfiles_read_certs(dovecot_t) ./modules/services/nscd.te:miscfiles_read_certs(nscd_t) ./modules/services/ldap.te:miscfiles_read_certs(slapd_t) ./modules/services/automount.te:miscfiles_read_certs(automount_t) ./modules/services/postfix.if: miscfiles_read_certs(postfix_$1_t) ./modules/services/sasl.te:miscfiles_read_certs(saslauthd_t) ./modules/services/apache.te:miscfiles_read_certs(httpd_t) ./modules/services/squid.te:miscfiles_read_certs(squid_t) I just added hal and automount? From rmy at tigress.co.uk Fri Mar 31 19:36:02 2006 From: rmy at tigress.co.uk (Ron Yorston) Date: Fri, 31 Mar 2006 20:36:02 +0100 (BST) Subject: fc5: several troubles at my first attempt Message-ID: <200603311936.k2VJa24V026095@tiffany.internal.tigress.co.uk> Stephen Smalley wrote: >On Wed, 2006-03-15 at 19:08 +0200, Maxim Britov wrote: >> I have installed current fc5 by http about week or two ago. It updated from rawhide. >> It currently installed on hda2 and it ran from qemu. >> >> I see many avc denied messages in dmesg (repeated 210 times with different pids): >> audit(1142439027.188:2): avc: denied { search } for pid=349 comm="pam_console_app" name="var" dev=hda2 ino=210081 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir >> hda2 here is / > >Hmmm.../var should be labeled with system_u:object_r:var_t, not file_t. >Need to relabel? I'm seeing these too. My /var is on a separate partition. Could this be the cause of the problem? Mar 31 20:04:18 random kernel: audit(1143831757.360:451): avc: denied { search } for pid=1384 comm="pam_console_app" name="var" dev=hde3 ino=62785 scontext=system_u:system_r:pam_console_t:s0-s0:c0.c255 tcontext=system_u:object_r:file_t:s0 tclass=dir Mar 31 20:04:18 random kernel: EXT3 FS on hde3, internal journal Mar 31 20:04:18 random kernel: SELinux: initialized (dev tmpfs, type tmpfs), uses transition SIDs Mar 31 20:04:18 random kernel: kjournald starting. Commit interval 5 seconds Mar 31 20:04:18 random kernel: EXT3 FS on hde8, internal journal Mar 31 20:04:18 random kernel: EXT3-fs: mounted filesystem with ordered data mode. Mar 31 20:04:18 random kernel: SELinux: initialized (dev hde8, type ext3), uses xattr # df Filesystem 1K-blocks Used Available Use% Mounted on /dev/hde3 972564 353452 568912 39% / /dev/hde8 972532 290180 632152 32% /var # ls -Zd /var drwxr-xr-x root root system_u:object_r:var_t /var # ls -id /var 2 /var Ron From tibbs at math.uh.edu Fri Mar 31 20:02:57 2006 From: tibbs at math.uh.edu (Jason L Tibbitts III) Date: Fri, 31 Mar 2006 14:02:57 -0600 Subject: FC5 LDAP issues In-Reply-To: (Jason L. Tibbitts, III's message of "Thu, 30 Mar 2006 18:07:29 -0600") References: <442C3BFA.7060206@redhat.com> <442C3F6D.3070901@redhat.com> <442C5943.3010802@redhat.com> <442C5D66.8010700@redhat.com> Message-ID: Just FYI, I installed the rawhide policy and it does fix this problem. The system boots fine in enforcing mode. Lots of other denials, most of which are from pam_console_app but also some that keep boot-time NFS mounts from working. I'm assuming it's just not a good idea to be running the rawhide policy on otherwise stock FC5, so I'll go back to permissive mode with the old policy until an update arrives. If, however, you'd like for me to report problems then I'd be happy to do so. I gather that I'm the only person running FC5, selinux and LDAP over SSL so perhaps my setup is odd in other ways that may be useful to you. - J<