login tries to write to /var/run/umtp

[meyerm]

Hi,

I'm using the ACL below for my login process. But it is just not allowed to read/write to /var/run/umtp.

Code: Select all

Sep 26 16:13:18 mm-master kernel: grsec: attempt to open /var/run/utmp for reading writing by (login:1522) UID(0) EUID(0), parent (init:1) UID(0) EUID(0)

I'm not quite sure if this is some kind of bug or my own fault. (I'm using 1.9.7).

Thank you
Marcel

Code: Select all

/bin/login o {
        /etc/shadow                             r
        /etc/ld.so.cache                        r
        /etc/login.defs                         r
        /var/run                                r # doesn't make any difference if left out
        /var/run/umtp                           rw
        /var/log
        /var/log/faillog                        rw
        /dev/tty6                               rw
        /dev/tty5                               rw
        /dev/tty4                               rw
        /dev/tty3                               rw
        /dev/tty2                               rw
        /dev/tty1                               rw
        /dev
        /lib/ld-linux.so.2                      rx
        /lib/libc.so.6                          rx
        /lib/libcrypt.so.1                      rx
        /lib/libdl.so.2                         rx
        /lib/libnsl.so.1                        rx
        /lib/libpam.so.0                        rx
        /lib/libpam_misc.so.0                   rx
        /lib/libnss_compat.so.2                 rx
        /lib/security                           rx
        /usr/lib/libcrack.so.2.7                rx
        /bin/login                              x
        /bin/bash                               x
        /root/.bash_history                     a
        /home/lxadmin/.bash_history             a
        /                                       r

        -CAP_ALL
        +CAP_SYS_TTY_CONFIG
        +CAP_CHOWN
        +CAP_SETGID
        +CAP_SETUID
        +CAP_FSETID

        connect {
                disabled
        }

        bind {
                disabled
        }
}

[spender]

strange....use gradm -T /bin/login /var/run/utmp and paste what it says

-Brad

[meyerm]

Cool, thanks. You helped me more than you can imagine...

You asked for /var/run/utmp while I wrote umtp in my post... That confused me and... right. I just mistyped it in my ACL! Oh man, soooo stupid.

Well, I think I have to look through all my ACLs to find other typos (I thought that gradm would check before loading the ACLs and complaining about wrong ones. Well, I was wrong (But I think I understand why this is a feature and not a bug! )

Now I will only have to achieve to get this "Usage: init" to disappear and I'm remotivated... *g*

Thanks

[asok]

Making "Usage: init" disappear will probably be harder than the umtp->utmp mistyping. For some reason, while loading the ACLs, gradm runs all the statically linked binaries (but I know way too little of the dynamic linker to try and fix it ).

[spender]

you can fix it by just removing the add_binary_libs() function call in gradm. I wrote it to ensure that when you made your process acl, it would always contain enough so that the program could start up correctly. I had wanted to change it to actually scan the binary for the needed libraries, but haven't gotten around to it.

-Brad

[meyerm]

Meanwhile, regarding all those planned changes in 1.9.8 and then 2.0.0, I'm beginning to believe, I'm doing a quite senseless work here in setting up a masterserver using grsec 1.9.7...

I shouldn't tell it to the CTO I think

[spender]

wait till you see the diagram I'm making of the internal representation of the system tonight. It's crazy to say the least...but I've removed all the bottlenecks of the current system, simplified a lot of the common operations, and in general, I'm expecting a 100x performance increase. 1.9.7 is still good (after all, people have lived with less complete ACL systems), but lots is going to change in 1.9.8/2.0. I'm just trying to ensure that I have a good enough foundation so that further additions/maintenance will be easier.

And just to clear up while I'm making these changes...the current ACL system has poor performance for rename/delete/create. It's O(n) for those operations where n is the number of subject ACLs. This happens whether or not any changes need to be made to the ACL's state...so it's the reason for the .4% performance hit. I've changed delete to an O(1) operation...and create/rename will be O(1) also for the most common case, and in the worst case it will be the same as before...O(n). But most of the time it will be O(kn) where k is some constant which says for a given inode/dev, how many out of the total number of subjects that object applies to.

[meyerm]

Sure. Just go on! I'm looking forward to.

Oh, just curious: how much trouble will it make to convert all those 1.9.7 ACLs to the 1.9.8? And when do you think, you will release it?

I'm just asking because if you release 1.9.8 next week it doesn't makes much sense to work another 3 days to get every single daemon to work and then throw away the whole work.

[spender]

it'll be easy to convert them...i can write a script that will convert them for you. Basically instead of having blah { } as subjects, it's now:

subject:/filenamehere mode
objects here

There's a few other small things, but none of it is any big difference

Userspace is hard enough as it is...so I needed an easier and cleaner syntax to work with. With 1.9.7 (even though nobody probably even knew it) the syntax will allow you to have your entire acl set on one line.

Also with the new rewrite, because the include directive will simply take the contents of one file and put them into another, I won't be able to support displaying line numbers for errors. Instead I'll show the line that caused the problem, the current role and current subject. Because I have to merge all the included files into one large file that then gets parsed (all the include stuff is handled by the preprocessor) I don't see how to keep track of the line numbers without adding a huge amount of complexity.

-Brad

[spender]

2.0 won't be out for a while...I'm pretty sure now that it will take longer than a month. Everything's being completely rewritten...and for now all I can do is attack chunks of the problem, because to code certain things it depends on how other parts of the code work. It'll be a while before I get something that I can even start testing.

-Brad