On Wednesday 07 April 2004 13:42, Richard Hally wrote:

My first guess was that it was provided by anaconda 'cause supposedly you only get it if you do an install(rather than upgrade) but doing rpm -q--filesby pkg of anaconda does not show it. It look to me like it is a back door to turn off SELinux on an unsuspecting sysadmin. Richard Hally

Files created by %post scripts of rpms, or by the installer, don't usually get "owned" by any particular package.

If you have somebody on the system that can write to your /etc/sysconfig/selinux file while you have SELinux on and enabled, then it's time to review your SELinux rule set and who you're handing root accounts out to.

On Wednesday 07 April 2004 14:25, Richard Hally wrote:

Rpm can put files just about anywhere. The installer (anaconda) is a corner case but rpm certainly could be a method of attack and as you say rpm doesn't always account for a packages files. Looks like a trojaned rpm would work and be difficult to spot.

Which is why you shouldn't be installing rouge rpms that are unsigned by a trusted source (like Red Hat). And really, there are more direct and equally untrackable ways to own a box w/ a trojan rpm than disabling your SELinux.

On Wednesday 07 April 2004 15:27, Richard Hally wrote:

So you are saying that some one can "own a box" (whatever that means) while SELinux is in enforcing mode? And do what? :)

No, but if your SELinux policies are loose enough to allow a rouge rpm to overwrite /etc/sysconfig/SELinux, then you've got to re-evaluate your policies.

On Thu, 8 Apr 2004 09:16, Jesse Keating jkeating@j2solutions.net wrote:

On Wednesday 07 April 2004 15:27, Richard Hally wrote:

...

So you are saying that some one can "own a box" (whatever that means) while SELinux is in enforcing mode?

To "own a box" means to obtain illegal administrative access without the administrator knowing. It usually involves installing a modified login program, or a daemon that accepts logins on a special port to provide access to the attacker without changing /etc/passwd or /etc/shadow. Modern "root kits" include kernel modules to hide processes, files, and open network sockets.

...

And do what? :)

No, but if your SELinux policies are loose enough to allow a rouge rpm to overwrite /etc/sysconfig/SELinux, then you've got to re-evaluate your policies.

Currently we have no facility for different privilege levels for RPMs. Every time you run rpm it runs in the same context which gives it permission to write to almost every file in the system. There is currently no SE Linux option to install a hostile rpm without having it do whatever it wants.

If you run rpm with --noscripts and --notriggers then it should be limited in the damage it can cause. It can still put binaries in the path, so it could create /usr/kerberos/sbin/ls and wait for the administrator to run it (in my system /usr/kerberos/sbin is before /bin in the path).

To prevent damage from hostile rpms we need to have a different context for rpm, no scripts and no triggers as default, and any files that are executed by a user would have to trigger a domain transition.

Of course even a domain transition isn't really enough to prevent attacks through ptys.

At the moment if you don't trust someone to provide a good rpm then don't run their software.

Bill Nottingham wrote:

Brian Millett (bpm@ec-group.com) said:

...

I do not have the file /etc/sysconfig/selinux, nor can I find it using yum: shaka: sudo yum provides "/etc/sysconfig/selinux" Gathering header information file(s) from server(s) Server: Test Linux 2.6-test prerelease kernels for RHL9/rawhide Server: Fedora Core 1.91 - i386 - Base Server: Fedora Core RawHide Server: Livna.org Fedora Compatible Packages (stable) Server: Livna.org Fedora Compatible Packages (testing) Server: macromedia.mplug.org - Flash Plugin Finding updated packages Downloading needed headers Looking in available packages for a providing package No packages found Looking in installed packages for a providing package No packages found

So, other than the release notes which talk about it, where is it? What package provides it?

Nothing provides it. It can be written by system-config-securitylevel-tui.

Bill

Sorry, I just ran s-c-securitylevel-tui and it did not create it for me. Perhaps it is created some where else while running anaconda? :-\

Bill Nottingham wrote:

Richard Hally (rhally@mindspring.com) said:

...

...

Nothing provides it. It can be written by system-config-securitylevel-tui.

Sorry, I just ran s-c-securitylevel-tui and it did not create it for me. Perhaps it is created some where else while running anaconda? :-\

Check --help... the bits for it are only activated via the CLI at the moment.

Bill

Ah, a work in progress... ok, so the UI that is on the way will have a setting to make it one of three values? The purpose of the file is to set one of the three values when the system boots but not change it on the fly while the system is up? OK, so the next question is where is that file read and used ? the init program? sysinit? I get the impression that it will be overridden by kernel parameters, how does that happen? Last question, has consideration been given to changing the value in that file when someone changes the actual status of SELinux(enforcing or permissive) with setenforce. Sorry for all the questions, but I am trying very hard to understand as mush as I can about SELinux. Thanks for your help, Richard Hally

Bill Nottingham wrote:

Richard Hally (rhally@mindspring.com) said:

...

The purpose of the file is to set one of the three values when the system boots but not change it on the fly while the system is up?

Mainly to set the value when the system boots, although it will change the enforcing level if you change it while it's operational.

...

OK, so the next question is where is that file read and used ? the init program? sysinit?

By init, yes.

...

I get the impression that it will be overridden by kernel parameters, how does that happen?

It's a priority mechanism - kernel parameters (selinux=0, or enforcing=(1|0)) take precedence, then the values in /etc/sysconfig/selinux, then whatever the kernel default is.

...

Last question, has consideration been given to changing the value in that file when someone changes the actual status of SELinux(enforcing or permissive) with setenforce.

Not really... setenforce is (IMO) used for temporary changes.

/selinux/enforce value changes depending whether you are enforcing mode or not. Of course you can report this via getenforce.

Bill

On Fri, Jun 04, 2004 at 09:57:36AM -0400, Daniel J Walsh wrote:

Todays selinux-polcy-* RPMS attempt to handle the /etc/selinux/config and /etc/sysconfig/selinux files in the post install.

What is supposed to be now a graph of dependencies between various packages in this group? AFAICS selinux-policy-strict, or selinux-policy-targeted, which look like they are mutually exclusive, is supposed to replace older policy and a similar deal is for policy-sources. But there are packages policytools and policytools-gui (I do not have them handy right now so I may misremember names), which got installed at some moment in a testing cycle, and which depend on policy. These packages seem to provide some utilities which do not have newer counterparts. Should they be gone? Replaced with something else?

Michal

On Fri, 2004-06-04 at 12:11, Michal Jaegermann wrote:

What is supposed to be now a graph of dependencies between various packages in this group? AFAICS selinux-policy-strict, or selinux-policy-targeted, which look like they are mutually exclusive, is supposed to replace older policy and a similar deal is for policy-sources. But there are packages policytools and policytools-gui (I do not have them handy right now so I may misremember names), which got installed at some moment in a testing cycle, and which depend on policy. These packages seem to provide some utilities which do not have newer counterparts. Should they be gone? Replaced with something else?

setools and setools-gui. There are updated versions available in the devel tree.