[opensuse] SECURITYQ: anyone experience w/using sockd (dante-server)?
Have a question on a config option I recently noticed (am trying to debug a coredumping prob, but if I am certain I get all the config options 'right', maybe the coredump will disappear... not that it should coredump over bad config in any case, 'ideally', but error handling is often, *in practice*, considered a 'luxury' often not high on a list of priorities). But in regards to security, found this section, that if it is to be believed, is "important": ( :-) ) --------------------- # # An important section, pay attention. # # when doing something that can require privilege, it will use the # userid "sockd". #user.privileged: sockd # when running as usual, it will use the unprivileged userid of "sockd". # user.notprivileged: sockd # If you compiled with libwrap support, what userid should it use # when executing your libwrap commands? "libwrap". #user.libwrap: libwrap ---------------------- If sockd needs to do something "privileged", (like, I assume(?), connect to a privileged port (<1024), wouldn't it (shouldn't it?) need to be 'root'? So wouldn't/shouldn't a logical choice for a privileged user be 'root' and not 'sockd' as is _indicated_ in the comments? "user.privileged" would be set to 'root', and not 'sockd'? I mean, I have an 'unprivileged user(&group) sockd - which it will user for (I assume) most operations, and only use the privileged setting when it needs something requiring a 'root priv'(?). Also -- what is common practice for use of "libwrap"? I'd never seen using a separate user just to access libwrap files. Is that common practice with anyone? ------- If anyone knows of any common 'gotcha's in moving from suse10.3 sockd (dante-server 1.1.19-72) to 11.1's sockd (dante-serv 1.1.19.127.32) I'd appreciate any heads-up warnings... Thanks for any help and answers... Linda -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
Linda Walsh wrote:
I'm trying to debug a core-dump prob, but, if I am certain that I get all the config options 'right', maybe the coredump will disappear...
It was a bad SECURITY configuration, after-all...*sigh*. (Not that I'd disagree with the default settings for most people -- but most people aren't forward-porting a server config that's been working (and ported forward with version changes) since SuSE 7.0 (~2000-2001). One of the important config options that I didn't even know was turned on was causing the problems. After I fixed my 'ntp' problem my sockd problem went away as well -- no more coredumping. Essentially my kernel had a bit of extra "security" in it that was turned on and "silently" biting some of my services in the posterior. I say silently, only because my 'standard' bit of looking for common messages (unless I know I put them in another directory, almost exclusively for sake of permissions (i.e. so a subdir can have matching user:group ownership to allow writeability ownership by non-root daemons)) involves: "ls -rt /var/log" and looking for what files have recently changed (within some period of interest). When I see no err's in recent log files, I assume things are good unless it's a log for a non-root daemon. Got suckered by 'audit.log' being in it's own 'audit' subdirectory for no _apparent_ reason (owned by root.root)? But wouldn't have really helped anyway, as I knew I didn't want or need auditing just yet and had turned auditing off. Also, AFAIK, auditing was limited in its functionality, anyway -- or used to be. Reminiscing: Some years ago, I tried to explain why I wanted certain auditing hooks in file-access routines, only to be told I didn't know what I was talking about. I wanted to have discretionary permissions checked before mandatory permission checks (mandatory, being administrative-file-permissions that weren't changeable at the discretion of a non-admin (non-root) user -- like 'ext2/3/4', append-only and immutable flags. If a user was 'shut-out' by discretionary flags (i.e. file not writeable as decided by the file mode bigs (user,group,other), then I didn't care. But if the user somehow got write-access to the file (became root, or was in group w/group write, or other-got set to +w), and THEN they tried 'illegally' access such a file (immutable or append-only), then I wanted to have it 'audited' or 'logged'. I was told my requirements were unrealistic and that I was just asking for "too much" and I should be happy w/whatever bones were tossed my way. At that point, I realized the people I was dealing had their own preconceptions of 'security' that didn't jive with mine (in fact, for a long time, 'auditing' wasn't considered any part of 'security', nor any reason to add hooks to the LSM security set -- and if I couldn't come up with a 'real security policy', that didn't involve 'auditing', to justify the hooks I wanted, then forget it. But...that was years ago (8-9 years ago). Ancient history...:-) Anyway, I think AppArmor might explain some of my other oddities -- but shouldn't jump to conclusions. AppArmor (or some other mandatory security policies) would likely be good to add at some point (but just trying to get things working again first). My 'server' is mostly serving internal networks only, at this point, so my security-setup doesn't mandate something like AppArmor, just yet...:-) I hadn't realized how badly 'apparmor' interfered with configuring services that were already working. Maybe if the services hadn't been working in the first place, I wouldn't have gotten the hint about several unexplained problems.... But the following seems to have fixed most of the broken service problems I was having:
chkconfig boot.apparmor off /etc/rc.d/boot.apparmor stop
Oh well... -- To unsubscribe, e-mail: opensuse+unsubscribe@opensuse.org For additional commands, e-mail: opensuse+help@opensuse.org
participants (1)
-
Linda Walsh