?

Log in

No account? Create an account

Previous Entry Share Next Entry
I followed all the rules and built policy with audit2allow and the semodule command blows up; :^(
danwalsh
This blog entry was prompted by a conversation I had with  "iv" on the Fedora-SElinux chat room

He was trying to write policy that allowed sshd to read /etc/shadow.

He followed my instructions from previous blogs but ended up getting a compiler error.

libsepol.check_assertion_helper: assertion on line 0 violated by allow sshd_t shadow_t:file {read } and Expand module failed

The problem was that he needed to satisfy an SELinux constraint.

One of the parts of the SELinux policy language is the ability to define constraints.

Constraints are defined using the neverallow command.  Constraints are used to prevent people from writing bad policy, or in the case of MLS, to enforce  rules governing information flow.

In targeted policy we have a rule

neverallow ~can_read_shadow_passwords shadow_t:file read;

This command says DON'T allow policy to be compiled which would allow a process type to read files labeled shadow_t, unless that process type also has the attribute "can_read_shadow_passwords";

So "iv" wrote a rule in his policy module that said

allow sshd_t shadow_t:file r_file_perms;

And when the compiler tried to compile this, it conflicted with the constraint and blew up.

"iv" has a couple of things he could do to allow this.

He could change his code to add the can_read_shadow_passwords attribute;

require {
    attribute can_read_shadow_passwords;
}

type sshd_t;
typeattribute sshd_t can_read_shadow_passwords;

allow sshd_t shadow_t:file r_file_perms;

Or he could use the auth_read_shadow interface

auth_read_shadow(sshd_t)
allow sshd_t shadow_t:file r_file_perms;

Or the best solution, just say no to allowing sshd to read the shadow password.  :^)

sshd currently uses PAM to check passwords.  One of the PAM modules that sshd uses is pam_unix. This module first tries to read /etc/shadow directly.  If it gets permission denied it executes /sbin/unix_chkpwd. unix_chkpwd accepts the user name and password and indicates to pam_unix whether the password matches the username.

unix_chkpwd is hundreds of lines of code, versus the thousands of lines of code in sshd.  So it is considered a lot easier to verify the security of unix_chkpwd.  Targeted policy only allows the unix_chkpwd (chkpwd_t) and unix_update (updpwd_t)  programs to read /etc/shadow.  Targeted policy has been written for confined programs that link to PAM to allow them to  transition to  the chkpwd_t and the updpwd_t domains when they execute the helper programs.

Now if a remote exploit of sshd were to be found which allowed crackers to read files remotely via sshd, or worse write them,  SELinux would prevent sshd_t from reading the /etc/shadow file and most other important files on the system.

  • 1

Does it indicate which assertion is failing?

(Anonymous)
From the above, it looks like it doesn't output which assertion is failing.

Might improve usability if it gave that, perhaps also with a human-readable version; e.g.:

libsepol.check_assertion_helper: assertion "neverallow ~can_read_shadow_passwords shadow_t:file read;" on line 0 violated by "allow sshd_t shadow_t:file {read }" and Expand module failed

or:

constraint "Never allow objects without "can_read_shadow_passwords" to read shadow_t files" violated by "allow sshd_t shadow_t:file {read }"

or somesuch

Re: Does it indicate which assertion is failing?

(Anonymous)
Or even:
constraint "Only contexts with "can_read_shadow_passwords" may read shadow_t files"
violated by "allow sshd_t shadow_t:file {read }"


?

Re: Does it indicate which assertion is failing?

No currently this does not, although this is a great suggestion, and I will bring it up with the upstream developers.

There is a mistake in my post above, pointed out to me by Joshua Brindle.

>On your article below though, it really mixes up assertions and
>constraints. Assertions are neverallow rules, they are compile/link
>time invariants. Constraints are runtime removal of permissions that
>would be otherwise granted, contingent on the constraint being
>satisfied.

neverallow rules are for compile/link time assertions.

constraints in terms of MLS are generated using the mlsconstrain
# new file labels must be dominated by the relabeling subjects clearance
mlsconstrain { dir file lnk_file chr_file blk_file sock_file fifo_file } relabelto
( h1 dom h2 );

Sorry about the mistake.

Need help

(Anonymous)
Great,
I think that my wife unfaithful to me. My e-mail is davidxleon1964@yahoo.co.uk.
I have a wonderful plan for disclosure of her deceit.
WBR,
David
http://world-viagra.com - my favourite pharma supermaket

Re: I followed all the rules and built policy with audit2allow and the semodule command blows up; :^

This information is very helpful. But many things changed since September 14th, 2007. Right now a module to allow an arbitrary program to read shadow appears to load without any errors in Fedora 15. Were neverallow removed?

Re: I followed all the rules and built policy with audit2allow and the semodule command blows up; :^

Yes we removed the neverallow checks from a running system, because it was taking so long for the policy recompile. Now we only check when we build the base policy. If you want to turn on the neverallow check you can do this by editing /etc/selinux/semanage.conf and setting expand-check=1

# expand-check check neverallow rules when executing all semanage commands.
# Large penalty in time if you turn this on.
expand-check=0

  • 1