Re: selinux versus chcon
On Mon, 2011-09-19 at 16:01 -0400, Fulko Hew wrote: On Mon, Sep 19, 2011 at 3:32 PM, Eric Paris epa...@redhat.com wrote: On Mon, 2011-09-19 at 14:49 -0400, Fulko Hew wrote: If so... why use chcon versus the semanage/restorecon technique? or if my assesement is wrong... can someone point me to a better explanation/tutorial? ... snip ... So semanage+restorecon == will last, chcon == will likely get blown away and make you angry later. Thanks for confirming that for me. Now my next issue is 'apparently' unknown contexts. My original RPM spec file added the 'httpd_sys_rw_content_t' context to a directory. Which was great for the versions of Fedora I was testing on, but now in RHEL 5.6 semanage complains with: type 'httpd_sys_rw_content_t' not defined. So it seems that my %post section of my RPM file has to either 'know' what distribution or version of selinux support is installed so I can avoid attempting to use types that are not defined, or having some way of finding out what 'types' are available 'in this OS' so that I issue the 'appropriate commands'. How can I find out what 'types' are available'? seinfo -t -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 08:53 -0400, Daniel J Walsh wrote: The memory problem is just the share number of file context that we are loading, each line of the file_context file is a regex. Currently the file_context file on my Rawhide machine is 4209 lines. If we can determine the only file context that systemd will need, based on directories we can eliminate some of the regexes. For example if we just loaded paths that begin with /var, /tmp, /dev, we would drop the regexs down to 1500. selabel_close() will free all of the file contexts mapping. So if you can bracket the usage of the mapping with a selabel_open();...;selabel_close();, then you'll only be consuming the memory when using the file contexts mapping. You don't want to do that around every file creation / relabel, of course. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd: please stop trying to take over the world :)
On Tue, 2011-06-14 at 10:03 +0200, Lennart Poettering wrote: On Mon, 13.06.11 18:18, Denys Vlasenko (dvlas...@redhat.com) wrote: On Sat, 2011-06-11 at 10:17 +0200, drago01 wrote: On Fri, Jun 10, 2011 at 3:07 PM, Denys Vlasenko dvlas...@redhat.com wrote: Hi Lennart, systemd is eating a lot more memory than any other init process I ever played with. Granted, systemd does a bit more that typical init, but I think using *eleven plus megabytes* of malloced space is a bit much. Sloppy attitude like this is the reason just about any daemon (more and more of which pop up like mushrooms in every new release, I must add) eats at least a few megabytes of RAM. It's quite pathetic, really. You can easily tell which software was developed earlier just by looking at its memory usage. Example from my machine: Good old ssh-agent: 404 kbytes. Shiny new dconf-service: 2452 kbytes. Shinier newer polkitd: 2836 kbytes. e-addressbook-factory: 5488 kbytes. Of course. What did you think. *Addressbook*! (Empty one in my case). No way empty addressbook can fit into 0.5 meg, it needs 5! :( :( :( ~11MB equals ~8 cents of RAM ... so meh. Are you volunteering to buy more RAM for every Fedora user? ;) As mentioned this is primarily the SELinux policy which we load into RAM. I wished libselinux would optimize resource usage transparently a bit better, but even without that we should be able to optimize this a bit in the way systemd loads the policy. SELinux makes boot slower and uses more resources, there is no news in that. There's also no news in the fact that we can definitely optimize its impact wherever we are aware of it. Just to clarify: what is unique here is a long-running daemon that is loading the entire file_contexts configuration into memory and keeping it there for its entire lifetime. Previously, the closest analogy was udev, which was quickly optimized to only load entries under /dev. Old init systems didn't load the file contexts configuration at all; they didn't need it for anything. systemd needs it because it handles creation and labeling of files and sockets that used to be either handled by the daemons themselves (in which case policy could transparently label them based on their creator) or by rc scripts that would fork+exec short-lived restorecon processes to fix up labels. Ways to improve the situation for systemd would include: - Only load a subset of file_contexts entries, similar to udev. - Only load the file contexts entries temporarily, using selabel_open + selabel_close to bracket entire blocks where files are created or relabeled. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: [systemd-devel] systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Mon, 2011-05-02 at 19:29 +0200, Lennart Poettering wrote: On Mon, 02.05.11 12:09, David Quigley (seli...@davequigley.com) wrote: Merging the kernel patch without doing the legwork for userspace first is a very bad idea. The kernel is what mounts the FS under /selinux so if you have it mount under /sys/fs/selinux instead without coordinating with the required usespace changes you'll have a completely broken system. I'd say let Dan handle when the right time to merge the kernel patch is since both him and the tresys people will have to be involved with releasing new versions of libselinux . Also Dan will have to work with some of the package maintainers to cleanup and fix their packages as well. I'd really not like it if I can't test new kernels with my labeled-nfs patches because we merged an ABI breaking change into mainline without making sure people can handle it first. No, userspace mounts the fs to /selinux. If the kernel patch is merged (and it will, given that Dan okey'd it) this wil just create an empty directory in /sys/fs/selinux suitable as mount point. That's all. Whether this is actually used as mount point is left to userspace. Merging the kernel patch is pretty much risk-less. The transition to it can happen at a later point, slowly, at a pace defined by Dan. Yes, agreed. This does require updating various scripts that directly reference /selinux though, including anaconda, dracut, puppet, etc. I'm guessing that some of these direct references are due to scripts that need to be able to run before /usr is mounted, so if we moved the libselinux utils to /bin or /sbin, then the scripts could execute selinuxenabled, getenforce, and setenforce without concern. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: systemd - move /selinux to /sys/fs/selinux - maybe remove /srv ?
On Fri, 2011-04-29 at 00:37 +0200, Michał Piotrowski wrote: Hi, I think it's a very good decision - I never understood why selinux dir is directly under /. I guess I missed some discussion of this. You'd need to update libselinux at least, definition of SELINUXMNT in libselinux/src/policy.h, used by selinux_init_load_policy() to mount selinuxfs for initial policy load. And it may break rc scripts and other scripts/programs that have become accustomed to /selinux. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux: rhel5 x fedora 14
On Wed, 2011-01-12 at 21:03 +, Paul Howarth wrote: On Wed, 12 Jan 2011 13:02:21 -0500 Daniel J Walsh dwa...@redhat.com wrote: On 01/12/2011 06:29 AM, Paulo Cavalcanti wrote: Hi, I have two HDs on my computer: one with rhel5 5.5 and the other with fedora 14. Both systems share some directories located in a common /home, mainly used by the httpd process. The problem is that selinux in fedora 14 uses unrestricted_u by default for all users, which rel5 does not understand, and any file labeled that way is treated as unlabeled_t in rhel5. I tried to relabel all files in Fedora 14 using chcon -R -u user_u -t user_home_t , for instance, but every new file is still created as unrestricted_u. I know very little about selinux, and I would like to know how to force all files in F14 to be user_u, but keeping the user owning those files, unrestricted. Is that possible? Is there a better solution for not having tons of denials in rhel5? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ One solution would be to mount with a context on one of the platforms. On RHEL5 mount the users homedir with a context of nfs_t, and set the boolean to say allow nfs homedirs mount -o context=system_u:object_r:nfs_t:s0 /dev/ABC /home setsebool -P use_nfs_home_dirs 1 What happens with newly-created files whilst booted in RHEL-5 in this case? What will Fedora 14 see them as? Not sure what the RHEL-5 kernel does; in modern kernels, it won't set a context on disk when creating new files in a filesystem mounted with context= and thus they will show up as unlabeled if mounted without a context= mount option in Fedora-14. You could mount it with a context= option in both, or run restorecon on it when booting Fedora-14. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux: rhel5 x fedora 14
On Thu, 2011-01-13 at 08:02 -0200, Paulo Cavalcanti wrote: On Wed, Jan 12, 2011 at 7:07 PM, Daniel J Walsh dwa...@redhat.com wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 01/12/2011 04:03 PM, Paul Howarth wrote: On Wed, 12 Jan 2011 13:02:21 -0500 Daniel J Walsh dwa...@redhat.com wrote: On 01/12/2011 06:29 AM, Paulo Cavalcanti wrote: Hi, I have two HDs on my computer: one with rhel5 5.5 and the other with fedora 14. Both systems share some directories located in a common /home, mainly used by the httpd process. The problem is that selinux in fedora 14 uses unrestricted_u by default for all users, which rel5 does not understand, and any file labeled that way is treated as unlabeled_t in rhel5. I tried to relabel all files in Fedora 14 using chcon -R -u user_u -t user_home_t , for instance, but every new file is still created as unrestricted_u. I know very little about selinux, and I would like to know how to force all files in F14 to be user_u, but keeping the user owning those files, unrestricted. Is that possible? Is there a better solution for not having tons of denials in rhel5? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ One solution would be to mount with a context on one of the platforms. On RHEL5 mount the users homedir with a context of nfs_t, and set the boolean to say allow nfs homedirs mount -o context=system_u:object_r:nfs_t:s0 /dev/ABC /home setsebool -P use_nfs_home_dirs 1 What happens with newly-created files whilst booted in RHEL-5 in this case? What will Fedora 14 see them as? Paul. nfs_t, i think so Stephens solution is probably better? I would hope in stephens solution they would be labeled user_home_t. But it would probably be smart to run restorecon -R -v ~/ When you login on F14 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/ I would like to thank you all for the suggestions. In rhel5, I changed my fstab this way: LABEL=/home /home ext4 defaults,context=user_u:object_r:user_home_t:s01 2 All the files labelled unconfined_u:object_r:user_home_t:s0 in F14 are seen as user_u:object_r:user_home_t:s0 in rhel5, and my /var/log/mesages is not no longer full of denials. However, even allowing httpd to read user content on rhel5 (files labelled user_home_t, I guess), I still get some warnings from selinux troubleshooter. Does this flag really work on rhel5? Can you show the actual messages from setroubleshoot or from the output of /sbin/ausearch -m AVC -ts today -i? Does anyone think that using nfs_t (and setsebool -P use_nfs_home_dirs 1) would make any difference? Also, does anyone know whether rhel6 will be more Fedora like, from an selinux point of view? RHEL-6 includes a version of SELinux that is far more modern than RHEL-5, naturally, and thus will look more like a modern Fedora (circa Fedora 12/13, I think). RHEL-5 was forked from Fedora 6 IIRC. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux: rhel5 x fedora 14
On Thu, 2011-01-13 at 08:14 -0500, Stephen Smalley wrote: On Wed, 2011-01-12 at 21:03 +, Paul Howarth wrote: On Wed, 12 Jan 2011 13:02:21 -0500 Daniel J Walsh dwa...@redhat.com wrote: On 01/12/2011 06:29 AM, Paulo Cavalcanti wrote: Hi, I have two HDs on my computer: one with rhel5 5.5 and the other with fedora 14. Both systems share some directories located in a common /home, mainly used by the httpd process. The problem is that selinux in fedora 14 uses unrestricted_u by default for all users, which rel5 does not understand, and any file labeled that way is treated as unlabeled_t in rhel5. I tried to relabel all files in Fedora 14 using chcon -R -u user_u -t user_home_t , for instance, but every new file is still created as unrestricted_u. I know very little about selinux, and I would like to know how to force all files in F14 to be user_u, but keeping the user owning those files, unrestricted. Is that possible? Is there a better solution for not having tons of denials in rhel5? Thanks. -- Paulo Roma Cavalcanti LCG - UFRJ One solution would be to mount with a context on one of the platforms. On RHEL5 mount the users homedir with a context of nfs_t, and set the boolean to say allow nfs homedirs mount -o context=system_u:object_r:nfs_t:s0 /dev/ABC /home setsebool -P use_nfs_home_dirs 1 What happens with newly-created files whilst booted in RHEL-5 in this case? What will Fedora 14 see them as? Not sure what the RHEL-5 kernel does; in modern kernels, it won't set a context on disk when creating new files in a filesystem mounted with context= and thus they will show up as unlabeled if mounted without a context= mount option in Fedora-14. You could mount it with a context= option in both, or run restorecon on it when booting Fedora-14. Sorry, not unlabeled but rather with the default file context for files without an xattr, which in this case would be file_t. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux: rhel5 x fedora 14
On Thu, 2011-01-13 at 11:51 -0200, Paulo Cavalcanti wrote:
Here it goes:
type=SYSCALL msg=audit(01/13/2011 07:31:09.287:39) : arch=x86_64
syscall=lstat success=no exit=-13(Permission denied) a0=7ff594509d50
a1=73924c40 a2=73924c40 a3=2f534d50522f6c6d items=0 ppid=2230
pid=2270 auid=unset uid=apache gid=apache euid=apache suid=apache
fsuid=apache egid=apache sgid=apache fsgid=apache tty=(none) ses=unset
comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0
key=(null)
type=AVC msg=audit(01/13/2011 07:31:09.287:39) : avc: denied
{ getattr } for pid=2270 comm=httpd
path=/home/packages/rpms/myrpms-el5-x86_64/repodata dev=sda4
ino=31331129 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
Was this while running RHEL-5 or F-14? Is /home mounted with a context=
mount option? What does 'mount' show for /home and/or /home/packages
(if a separate mount)?
--
Stephen Smalley
National Security Agency
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux: rhel5 x fedora 14
On Thu, 2011-01-13 at 11:51 -0200, Paulo Cavalcanti wrote:
On Thu, Jan 13, 2011 at 11:28 AM, Stephen Smalley s...@tycho.nsa.gov
wrote:
On Thu, 2011-01-13 at 08:14 -0500, Stephen Smalley wrote:
On Wed, 2011-01-12 at 21:03 +, Paul Howarth wrote:
On Wed, 12 Jan 2011 13:02:21 -0500
Daniel J Walsh dwa...@redhat.com wrote:
On 01/12/2011 06:29 AM, Paulo Cavalcanti wrote:
Hi,
I have two HDs on my computer: one with rhel5 5.5 and
the other with
fedora 14.
Both systems share some directories located in a
common /home,
mainly used by the httpd process.
The problem is that selinux in fedora 14 uses
unrestricted_u by
default for all users, which rel5 does not understand,
and any file labeled that way is treated as
unlabeled_t in rhel5.
I tried to relabel all files in Fedora 14 using chcon
-R -u user_u
-t user_home_t , for instance,
but every new file is still created as
unrestricted_u.
I know very little about selinux, and I would like to
know how to
force all files in F14 to be user_u,
but keeping the user owning those files, unrestricted.
Is that possible? Is there a better solution for not
having tons of
denials in rhel5?
Thanks.
--
Paulo Roma Cavalcanti
LCG - UFRJ
One solution would be to mount with a context on one of
the platforms.
On RHEL5 mount the users homedir with a context of
nfs_t, and set the
boolean to say allow nfs homedirs
mount -o
context=system_u:object_r:nfs_t:s0 /dev/ABC /home
setsebool -P use_nfs_home_dirs 1
What happens with newly-created files whilst booted in
RHEL-5 in this
case? What will Fedora 14 see them as?
Not sure what the RHEL-5 kernel does; in modern kernels, it
won't set a
context on disk when creating new files in a filesystem
mounted with
context= and thus they will show up as unlabeled if mounted
without a
context= mount option in Fedora-14. You could mount it with
a context=
option in both, or run restorecon on it when booting
Fedora-14.
Sorry, not unlabeled but rather with the default file
context for
files without an xattr, which in this case would be file_t.
Here it goes:
type=SYSCALL msg=audit(01/13/2011 07:31:09.274:38) : arch=x86_64
syscall=stat success=no exit=-13(Permission denied) a0=7ff594509c30
a1=73924c40 a2=73924c40 a3=0 items=0 ppid=2230 pid=2270
auid=unset uid=apache gid=apache euid=apache suid=apache fsuid=apache
egid=apache sgid=apache fsgid=apache tty=(none) ses=unset comm=httpd
exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(01/13/2011 07:31:09.274:38) : avc: denied
{ search } for pid=2270 comm=httpd name=repodata dev=sda4
ino=31331129 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
type=SYSCALL msg=audit(01/13/2011 07:31:09.287:39) : arch=x86_64
syscall=lstat success=no exit=-13(Permission denied) a0=7ff594509d50
a1=73924c40 a2=73924c40 a3=2f534d50522f6c6d items=0 ppid=2230
pid=2270 auid=unset uid=apache gid=apache euid=apache suid=apache
fsuid=apache egid=apache sgid=apache fsgid=apache tty=(none) ses=unset
comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0
key=(null)
type=AVC msg=audit(01/13/2011 07:31:09.287:39) : avc: denied
{ getattr } for pid=2270 comm=httpd
path=/home/packages/rpms/myrpms-el5-x86_64/repodata dev=sda4
ino=31331129 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
type=SYSCALL msg=audit(01/13/2011 09:33:05.718:46) : arch=x86_64
syscall=stat success=no exit=-13(Permission denied) a0=7ff594509c00
a1=73924c40 a2=73924c40 a3=0 items=0 ppid=2230 pid=2271
auid=unset uid=apache gid=apache euid=apache suid=apache fsuid=apache
egid=apache sgid=apache fsgid=apache tty=(none) ses=unset comm=httpd
exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0 key=(null)
type=AVC msg=audit(01/13/2011 09:33:05.718:46) : avc: denied
{ search } for pid=2271 comm=httpd name=repodata dev=sda4
ino=31331129 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
type=SYSCALL msg=audit(01/13/2011 09:33:05.719:47) : arch=x86_64
syscall=lstat success=no exit=-13
Re: selinux: rhel5 x fedora 14
On Thu, 2011-01-13 at 09:12 -0500, Stephen Smalley wrote:
On Thu, 2011-01-13 at 11:51 -0200, Paulo Cavalcanti wrote:
Here it goes:
type=SYSCALL msg=audit(01/13/2011 07:31:09.287:39) : arch=x86_64
syscall=lstat success=no exit=-13(Permission denied) a0=7ff594509d50
a1=73924c40 a2=73924c40 a3=2f534d50522f6c6d items=0 ppid=2230
pid=2270 auid=unset uid=apache gid=apache euid=apache suid=apache
fsuid=apache egid=apache sgid=apache fsgid=apache tty=(none) ses=unset
comm=httpd exe=/usr/sbin/httpd subj=system_u:system_r:httpd_t:s0
key=(null)
type=AVC msg=audit(01/13/2011 07:31:09.287:39) : avc: denied
{ getattr } for pid=2270 comm=httpd
path=/home/packages/rpms/myrpms-el5-x86_64/repodata dev=sda4
ino=31331129 scontext=system_u:system_r:httpd_t:s0
tcontext=system_u:object_r:file_t:s0 tclass=dir
Was this while running RHEL-5 or F-14? Is /home mounted with a context=
mount option? What does 'mount' show for /home and/or /home/packages
(if a separate mount)?
Oh, and under what OS were those files created? RHEL-5 or F-14?
--
Stephen Smalley
National Security Agency
--
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Re: selinux: rhel5 x fedora 14
On Wed, 2011-01-12 at 09:29 -0200, Paulo Cavalcanti wrote: Hi, I have two HDs on my computer: one with rhel5 5.5 and the other with fedora 14. Both systems share some directories located in a common /home, mainly used by the httpd process. The problem is that selinux in fedora 14 uses unrestricted_u by default for all users, which rel5 does not understand, and any file labeled that way is treated as unlabeled_t in rhel5. I tried to relabel all files in Fedora 14 using chcon -R -u user_u -t user_home_t , for instance, but every new file is still created as unrestricted_u. I know very little about selinux, and I would like to know how to force all files in F14 to be user_u, but keeping the user owning those files, unrestricted. Is that possible? Is there a better solution for not having tons of denials in rhel5? When mounting /home under rhel5, add the context= option to your list of mount options, e.g. context=user_u:object_r:user_home_t:s0 Then your rhel5 system will treat all inodes under /home as if they were labeled with that context and will not read the values set by f14. -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
Re: Developers of packages please pay attention to selinux labeling.
On Thu, 2010-07-15 at 09:52 +0100, Richard W.M. Jones wrote: On Tue, Jul 13, 2010 at 04:47:40PM +0200, Tomasz Torcz wrote: There are sometimes such obvious errors and missing labels that I cannot imagine not catching an audit message when program fails to even start! A lot of my Fedora machines are virtualized and I only ever interact with them by ssh. While I would see a program if it failed to start, I don't generally see any SELinux audit messages ever. (The bloated python SELinux audit daemon whatever it's called is usually the first thing I kill when I install Fedora on my desktop too ...) You don't need setroubleshoot to see SELinux denials. /sbin/ausearch -m AVC -ts today -i (if running auditd) or grep avc /var/log/messages (if not). -- Stephen Smalley National Security Agency -- devel mailing list devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/devel
