sssd 1.8.4
Dear list members, does anyone use sssd 1.8.4? I try to set it up on on FreeBSD 9.1-RC3 but get no success. First of all, there is no log files under /var/log/sssd, so that I can not see, what is going wrong. I've edited two config files and expect to be able to list LDAP(SAMBA4) users but it doesn't work. Do I miss something here? -- sssd.conf -- [sssd] config_file_version = 2 reconnection_retries = 3 sbus_timeout = 30 services = nss, pam domains = DOM [nss] filter_groups = root filter_users = root reconnection_retries = 3 [pam] reconnection_retries = 3 [domain/DOM] debug_level = 7 # kerberos auth_provider = krb5 chpass_provider = krb5 krb5_server = srv.test.dom krb5_realm = TEST.DOM ldap_force_upper_case_realm = true # ldap id_provider = ldap timeout = 20 ldap_uri = ldap://srv.test.dom ldap_search_base = DC=test,DC=dom ldap_schema = rfc2307bis ldap_default_bind_dn = CN=Administrator,CN=Users,DC=test,DC=dom ldap_default_authtok_type = password ldap_default_authtok = secret ldap_user_uid_number = uidNumber ldap_user_gid_number = gidNumber ldap_user_object_class = user ldap_group_object_class = group ldap_user_home_directory = unixHomeDirectory ldap_user_principal = userPrincipalName ldap_account_expire_policy = ad enumerate = true nsswitsch.conf -- group: files sss group_compat: nis hosts: files dns networks: files passwd: files sss passwd_compat: nis shells: files services: compat services_compat: nis protocols: files rpc: files - I would be very appreciated for any help and hints. Best regards -- Alexey Tyurikov ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
SOLVED - Re: CARP within VirtualBox Does it work?
On Dec 4, 2012, at 8:17 PM, dweimer wrote: > On 2012-12-01 03:14, Damien Fleuriot wrote: >> On 30 November 2012 20:44, dweimer wrote: >>> On 2012-11-29 14:07, dweimer wrote: On 2012-11-29 12:53, Fleuriot Damien wrote: > > On Nov 29, 2012, at 6:43 PM, dweimer wrote: > >> I was trying to setup a test of CARP on two virtual machines running in >> VirtualBox 4.2.4r81684 I am not sure if I have something wrong with my >> CARP >> configuration or if VirtualBox just doesn't work right with it. I can >> only >> ping the CARP interface IP address from the machine listed as MASTER, if >> I >> do an ifconfig carp0 down on the MASTER the other machine correctly >> switches >> form BACKUP to MASTER and then I can ping the interface from it but not >> from >> the Original system. >> >> The VirtualBox systems are both using bridged networking, and the host >> cannot ping the carp0 IP address but can ping the interface IP address. >> >> Before I go through more trouble shooting, does anyone know if CARP >> doesn't work with VirtualBox? >> >> carp configuration >> Machine1: >> ifconfig_em0="UP" >> ifconfig_em0_name="LAN" >> ipv4_addrs_LAN="10.20.190.201/16" >> defaultrouter="10.20.111.2" >> cloned_interfaces="carp0" >> ifconfig_carp0="vhid 1 advskew 100 pass ReduntantCarpTest >> 10.20.190.203/16 >> >> ifconfig carp0: >> carp0 flags=49 metric 0 mtu 1500 >> inet 10.20.190.203 netmask 0x >> nd6 options=29 >> carp: MASTER vhid 1 advbase 1 advskew 100 >> >> >> Machine2: >> ifconfig_em0="UP" >> ifconfig_em0_name="LAN" >> ipv4_addrs_LAN="10.20.190.202/16" >> defaultrouter="10.20.111.2" >> cloned_interfaces="carp0" >> ifconfig_carp0="vhid 1 pass ReduntantCarpTest 10.20.190.203/16 >> >> ifconfig carp0: >> carp0 flags=49 metric 0 mtu 1500 >> inet 10.20.190.203 netmask 0x >> nd6 options=29 >> carp: BACKUP vhid 1 advbase 1 advskew 0 >> >> FreeBSD version is 9.1RC3 on both test machines. > > > > > We're using FreeBSD and CARP in virtualized environments at work, > albeit not on VirtualBox but on Proxmox/KVM. > > First, I would advise replacing 10.20.190.203/16 with 10.20.190.203/32 > > > I notice your carp0 is MASTER on machine1 with an advskew of 100 vs > machine 2 advskew 0, same advbase. > Confirm this is *after* you've set carp0 down on machine2. > > If both carps are up and machine1 with advskew 100 beats machine2 > with advskew 0, you have an additional problem. > > > See if you have any more luck with the /32 address on carp0 anyway. The documentation shows the mask matching that of the interface: hostname="hostb.example.org" ifconfig_fxp0="inet 192.168.1.4 netmask 255.255.255.0" cloned_interfaces="carp0" ifconfig_carp0="vhid 2 pass testpass 192.168.1.51/24" This is consistent with the man page for CARP on the system as well. Regardless I tried with the /32 and had the same result as I did with the /16. I had done various UP/DOWN on interfaces so the current MASTER was just the last one to have not been DOWN. I think I might just copy these VMs to my VMWARE Workstation 9 install on my home PC after work tonight and see if the problem persists. >>> >>> >>> The behavior definitely changed going from VirtualBox to VMWare, the only >>> change in my configuration was the IP addresses to match the home network. >>> However now I can talk to the carp interface form other machines, but they >>> receive two response one from each of the test systems. TCPDUMP shows that >>> they are each seeing the others broadcasts, but for some reason they are >>> both running as MASTER. If you run a DOWN/UP on the interface, it briefly >>> shows as BACKUP before switching to MASTER. I tried with both /24 subnet of >>> my home network, and setting the carp0 interface to /32, both behaved the >>> same. Any one have any other ideas, as to whether this comes down to a >>> Virtual Network Issue, or a setup issue on my part. >>> >> >> >> Well, it definitely works here for us on Proxmox/KVM. >> >> When you tcpdump on your either host, do you see the CARP >> advertisements from the other ? >> >> >> FInd below the advertisements as seen from our CARP backup firewall: >> $ sudo tcpdump -ni vlan14 vrrp >> tcpdump: verbose output suppressed, use -v or -vv for full protocol decode >> listening on vlan14, link-type EN10MB (Ethernet), capture size 96 bytes >> 10:11:09.084568 IP 195.158.240.[snip] > 224.0.0.18: VRRPv2, >> Advertisement, vrid 114, prio 50, authtype none, intvl 1s, length 36 >> 10:11:10.282826 IP 195.158.240.[snip] > 224.0.0.18: VRRPv2, >> Advertisement, vrid 114, prio 50, authtype none, intvl 1s, length 36 >> 10:11:11.48107
Save € 2,000 with Gan Direct All-in-One Insurance
Save € 2,000 by switching your Motor, Property and Health Insurance to Gan Direct All-in-One http://us4.campaign-archive1.com/?u=953e7a73414b04f0ff6056f55&id=d52abfa867&e=a8af35d56f (http://www.GanDirect.com?utm_source=New+Prospective+Customers&utm_campaign=d52abfa867-Pros_Bundled_offer11_28_2012&utm_medium=email) Save € 2,000 by switching your Motor, Property and Health Insurance to Gan Direct All-in-One We don't believe in empty promises. Gan Direct More for Less. Guaranteed. At Gan Direct, we believe in a world where life is simpler, easier, and more affordable. Now by switching your Motor, Property and Health Insurance to Gan Direct All-in-One you can save € 2,000 per year. The savings example is for the average family, with two cars, two children, in a four bedroom home with Health Insurance based on the most popular plan in Cyprus. And with Gan's Easy Switch service we will take the hassle off you by dealing with all the paperwork. Call us at 800 5 10 15. Gan Direct's All-in-One. Not just savings, but easy savings. Gan Direct | Simpler, Better, Faster The acceptance of your proposal is subject to terms and conditions and we reserve the right to decline Copyright © 2012 Gan Direct Insurance, All rights reserved. Our mailing address is: Gan Direct Insurance, PO Box 51998, 3509 Limassol ** forward to a friend (http://us4.forward-to-friend.com/forward?u=953e7a73414b04f0ff6056f55&id=d52abfa867&e=a8af35d56f) ** unsubscribe from this list (http://gandirect.us4.list-manage.com/unsubscribe?u=953e7a73414b04f0ff6056f55&id=63b7e8c64f&e=a8af35d56f&c=d52abfa867) ** update subscription preferences (http://gandirect.us4.list-manage.com/profile?u=953e7a73414b04f0ff6056f55&id=63b7e8c64f&e=a8af35d56f) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Save € 2,000 with Gan Direct All-in-One Insurance
Save € 2,000 by switching your Motor, Property and Health Insurance to Gan Direct All-in-One http://us4.campaign-archive1.com/?u=953e7a73414b04f0ff6056f55&id=d52abfa867&e=45a40e088c (http://www.GanDirect.com?utm_source=New+Prospective+Customers&utm_campaign=d52abfa867-Pros_Bundled_offer11_28_2012&utm_medium=email) Save € 2,000 by switching your Motor, Property and Health Insurance to Gan Direct All-in-One We don't believe in empty promises. Gan Direct More for Less. Guaranteed. At Gan Direct, we believe in a world where life is simpler, easier, and more affordable. Now by switching your Motor, Property and Health Insurance to Gan Direct All-in-One you can save € 2,000 per year. The savings example is for the average family, with two cars, two children, in a four bedroom home with Health Insurance based on the most popular plan in Cyprus. And with Gan's Easy Switch service we will take the hassle off you by dealing with all the paperwork. Call us at 800 5 10 15. Gan Direct's All-in-One. Not just savings, but easy savings. Gan Direct | Simpler, Better, Faster The acceptance of your proposal is subject to terms and conditions and we reserve the right to decline Copyright © 2012 Gan Direct Insurance, All rights reserved. Our mailing address is: Gan Direct Insurance, PO Box 51998, 3509 Limassol ** forward to a friend (http://us4.forward-to-friend.com/forward?u=953e7a73414b04f0ff6056f55&id=d52abfa867&e=45a40e088c) ** unsubscribe from this list (http://gandirect.us4.list-manage.com/unsubscribe?u=953e7a73414b04f0ff6056f55&id=63b7e8c64f&e=45a40e088c&c=d52abfa867) ** update subscription preferences (http://gandirect.us4.list-manage.com/profile?u=953e7a73414b04f0ff6056f55&id=63b7e8c64f&e=45a40e088c) ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: getpwnam_r returns EINVAL on FreeBSD 8.3
On Mon, Dec 3, 2012 at 5:54 PM, Dan Lists wrote:
> After upgrading a server from FreeBSD 7.3 to FreeBSD 8.3 I noticed
> this bug. Since upgrading, getpwnam_r is acting inconsistently. If I
> look up a user that does not exist and the name is 16 characters or
> less, getpwnam_r returns 0 and the result is NULL. If the name is
> more than 16 characters, getpwnam_r returns EINVAL. Everything works
> correctly for users that exist.
I was incorrect. The behavior of getpwnam_r is the same on 7.3 and
8.3. The software I was testing acted differently on the two
versions.
> This only happens when the nsswitch.conf passwd: line contains files.
> You need to use files if you are using another module such as msql or
> ldap. The problem exists without the other modules listed. For
> example:
>
> passwd: files
I would like to emphasize that this does NOT happen when passwd: is
set to compat. I believe this is a bug. getpwnam_r should have the
same return values (or errno for getpwnam) whether nsswitch.conf has
compat or files. If there is a really good reason for them to be
different, it should be documented.
> Below is a simple test program. Set passwd: to files in nsswitch.conf
> and run the program. Any idea how to fix this bug with getpwnam_r?
>
> #include
> #include
> #include
>
> main()
> {
> lookup("doesnotexist");
> lookup("doesnotexisty");
> }
>
> int lookup( char *name)
> {
>
> struct passwd pwd;
> char buffer[1024];
> struct passwd *result;
> int err;
>
> printf("\nLooking up: %s\n", name);
>
> err = getpwnam_r(name, &pwd, buffer, sizeof(buffer), &result);
>
> if( err != 0 ){
> printf("Return code: %d\n", err);
> }else if( result == 0 ){
> printf("Returned no result!\n");
> }else{
> printf("Returned: %s (%d)\n", result->pw_name, result->pw_uid);
> }
> }
___
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: installworld strangeness
On 11/22/12, David Noel wrote: > On 11/22/12, Paul Schmehl wrote: >> --On November 22, 2012 7:14:35 AM -0600 David Noel >> >> >> wrote: >> >>> Updating from 8.2 to 8.3 I'm running into the following: >>> >>> ===> include (install) >>> creating osreldate.h from newvers.sh >>> dirname: not found >>> *** Error code 127 >>> >>> Stop in /usr/src/include. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> *** Error code 1 >>> >>> Stop in /usr/src. >>> >>> Has anyone managed to work past this error message? >> >> I just upgraded a system from 8.2 to 8.3 without a problem. World build >> find as did kernel. >> >> It sounds like you're missing source files. >> >> Try fetching the source from svn and starting over. >> >> svn co svn://svn.freebsd.org/base/releng/8.3/ /usr/src >> >> Paul Schmehl, Senior Infosec Analyst >> > > I pulled with `svn co https://svn0.us-west.FreeBSD.org/base/releng/8.3 > /usr/src`, so everything should be in order there. > Out of frustration I resorted to the last measure of a clean install. I was afraid that I'd forgotten to record other filesystem changes and that they were causing the error so I figured it would be the easiest way to be sure. There was one mention of this error message on the questions mailing list that I'd missed earlier. In it the theory that file dates were causing the error message was discussed. Prior to reinstallation I ran `make -d A installworld` and in the verbose output was given a message supporting that theory: that the error was caused by sys/param.h being newer than osreldate.h, so it seems safe to say that was the cause. In retrospect though it seems strange. If that really was the case it makes little sense that a clean install would fix things. I built off of the exact same code so it stands to reason that error message should have presented itself again were the dates truly the cause. So I'm not entirely certain, unfortunately. At any rate, the problem has been resolved. For future readers struggling with a similar problem I'd suggest fiddling with the date-stamps to see if it resolves the error. Thanks, all. -David ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
12/5/2012
Hello freebsd-questions@freebsd.org , Please confirm if you are the owner of this email. Reply ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
grep -Dskip doesn't skip FIFOs
Hi there,
grep(1) does not seem to skip FIFOs when told to.
coco@probsd:~
uname -a
FreeBSD probsd.c0c0.intra 8.3-STABLE FreeBSD 8.3-STABLE #0 r243477: Sat Nov 24
11:07:17 CET 2012 root@x2.c0c0.intra:/usr/obj/usr/src/sys/GATEKEEPER i386
coco@probsd:~
mkfifo bleh
coco@probsd:~
ls -l bleh
prw-r--r-- 1 coco coco 0 Dec 5 23:55 bleh
coco@probsd:~
grep -Dskip foobar bleh
^C
coco@probsd:~
truss grep -Dskip foobar bleh
__sysctl(0xbfbfe074,0x2,0xbfbfe07c,0xbfbfe080,0x0,0x0) = 0 (0x0)
mmap(0x0,336,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 671711232 (0x28098000)
munmap(0x28098000,336) = 0 (0x0)
__sysctl(0xbfbfe0d8,0x2,0x2808ee7c,0xbfbfe0e0,0x0,0x0) = 0 (0x0)
mmap(0x0,32768,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,-1,0x0) = 671711232
(0x28098000)
issetugid(0x280878ab,0xbfbfe59c,0x104,0x0,0x0,0x0) = 0 (0x0)
open("/etc/libmap.conf",O_RDONLY,0666) ERR#2 'No such file or
directory'
open("/var/run/ld-elf.so.hints",O_RDONLY,00) = 3 (0x3)
read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\M-1\0\0"...,128) = 128 (0x80)
lseek(3,0x80,SEEK_SET) = 128 (0x80)
read(3,"/lib:/usr/lib:/usr/lib/compat:/u"...,177) = 177 (0xb1)
close(3) = 0 (0x0)
access("/lib/libgnuregex.so.5",0)ERR#2 'No such file or
directory'
access("/usr/lib/libgnuregex.so.5",0)= 0 (0x0)
open("/usr/lib/libgnuregex.so.5",O_RDONLY,00)= 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=5484738,size=64244,blksize=16384 }) = 0 (0x0)
pread(0x3,0x2808ddc0,0x1000,0x0,0x0,0x0) = 4096 (0x1000)
mmap(0x0,69632,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 671744000
(0x280a)
mmap(0x280a,65536,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 671744000 (0x280a)
mmap(0x280b,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xf000) =
671809536 (0x280b)
close(3) = 0 (0x0)
access("/lib/libbz2.so.4",0) ERR#2 'No such file or
directory'
access("/usr/lib/libbz2.so.4",0) = 0 (0x0)
open("/usr/lib/libbz2.so.4",O_RDONLY,027757760314) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=5484473,size=8,blksize=16384 }) = 0 (0x0)
pread(0x3,0x2808ddc0,0x1000,0x0,0x0,0x0) = 4096 (0x1000)
mmap(0x0,65536,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 671813632
(0x280b1000)
mmap(0x280b1000,61440,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 671813632 (0x280b1000)
mmap(0x280c,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xf000) =
671875072 (0x280c)
close(3) = 0 (0x0)
access("/lib/libz.so.5",0) = 0 (0x0)
open("/lib/libz.so.5",O_RDONLY,027757760314) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=5470199,size=72328,blksize=16384 }) = 0 (0x0)
pread(0x3,0x2808ddc0,0x1000,0x0,0x0,0x0) = 4096 (0x1000)
mmap(0x0,73728,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 671879168
(0x280c1000)
mmap(0x280c1000,69632,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 671879168 (0x280c1000)
mmap(0x280d2000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0x11000) =
671948800 (0x280d2000)
close(3) = 0 (0x0)
access("/lib/libc.so.7",0) = 0 (0x0)
open("/lib/libc.so.7",O_RDONLY,027757760314) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=5470167,size=1158944,blksize=16384 }) = 0 (0x0)
pread(0x3,0x2808ddc0,0x1000,0x0,0x0,0x0) = 4096 (0x1000)
mmap(0x0,1167360,PROT_NONE,MAP_PRIVATE|MAP_ANON|MAP_NOCORE,-1,0x0) = 671952896
(0x280d3000)
mmap(0x280d3000,1048576,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE,3,0x0)
= 671952896 (0x280d3000)
mmap(0x281d3000,28672,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED,3,0xff000) =
673001472 (0x281d3000)
mmap(0x281da000,90112,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,-1,0x0)
= 673030144 (0x281da000)
close(3) = 0 (0x0)
mmap(0x0,880,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 673120256 (0x281f)
munmap(0x281f,880) = 0 (0x0)
mmap(0x0,600,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 673120256 (0x281f)
munmap(0x281f,600) = 0 (0x0)
mmap(0x0,712,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 673120256 (0x281f)
munmap(0x281f,712) = 0 (0x0)
mmap(0x0,1048,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 673120256 (0x281f)
munmap(0x281f,1048) = 0 (0x0)
mmap(0x0,22000,PROT_READ|PROT_WRITE,MAP_ANON,-1,0x0) = 673120256 (0x281f)
munmap(0x281f,22000) = 0 (0x0)
sysarch(0xa,0xbfbfe140,0x2805d51b,0x2808d318,0x28070159,0x2808d318) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTERM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|SIGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0)
= 0 (0x0)
sigprocmask(S
Somewhat OT: Is Full Command Logging Possible?
This is a little bit outside the strict boundaries of a FreeBSD question, but I am hoping someone in this community has solved this problem and that I might be able to adapt it for non-FreeBSD systems (AIX and Linux, specifically). I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. The fact that they became root is logged, *but everything thereafter they do is not*. What these people need is something that does the following things - this need not be sudo based, any FOSS or commercial solution would be considered: - Log the fact that someone became effective root - Log every command they execute *as* root - If they run a script as root, log the individual actions of that script - Have visibility into all this no matter how they access the system - console, ssh, xterm Nothing I have found so far meets all these criterion. Verbose syslogging will not catch the case where you start a subshell from the main shell. Keylogging seems to only have limited coverage and does not appear it would work if, say, I log in via ssh and then kick off an xterm. Other solutions fail if I start an editor and shell out from there. The current proposal is to install sudo rules such that NO one is allowed 'sudo su -' and *every single command* you want to run as root has to start with 'sudo'. This has two big drawbacks: - It's an enormous pain for the admins and fundamentally changes their workflow - It cannot see into scripts. So I can circumvent it pretty easily with: sudo chown root:wheel my_naughty_script sudo chmod 700 my_naughty script sudo ./my_naughty_script The sudo log will note that I ran the script, but not what it did. So Gentle Geniuses, is there prior art here that could be applied to give me full coverage logging of every action taken by any person or thing running with effective or actual root? P.S. I do not believe auditd does this either. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
On Wed, Dec 5, 2012 at 5:19 PM, Tim Daneliuk wrote: > This is a little bit outside the strict boundaries of a FreeBSD question, > but I am hoping someone in this community has solved this problem and > that I might be able to adapt it for non-FreeBSD systems (AIX and Linux, > specifically). > > P.S. I do not believe auditd does this either. > Challenge your beliefs. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
On 6 Dec 2012, at 00:19, Tim Daneliuk wrote: > sudo chown root:wheel my_naughty_script > sudo chmod 700 my_naughty script > sudo ./my_naughty_script > > The sudo log will note that I ran the script, but not what it did. > > wow, way to complicate matters. sudo csh > So Gentle Geniuses, is there prior art here that could be applied > to give me full coverage logging of every action taken by any person or > thing running with effective or actual root? > > P.S. I do not believe Now would be a good time to start, then. The only things you need to ensure are: - auditd cannot be killed off (this is an interesting bit actually, anyone knows how to do that ?) - the audit trail files can only be appended to ; man chflags An alternative would be lshell, however you'll have to whitelist commands people can execute. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk wrote: > I am working with an institution that today provides limited privilege > escalation > on their servers via very specific sudo rules. The problem is that the > administrators can do 'sudo su -'. sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
On 12/05/2012 05:42 PM, Damien Fleuriot wrote: On 6 Dec 2012, at 00:19, Tim Daneliuk wrote: sudo chown root:wheel my_naughty_script sudo chmod 700 my_naughty script sudo ./my_naughty_script The sudo log will note that I ran the script, but not what it did. wow, way to complicate matters. Hey, I didn't dream up this problem :) sudo csh So Gentle Geniuses, is there prior art here that could be applied to give me full coverage logging of every action taken by any person or thing running with effective or actual root? P.S. I do not believe Now would be a good time to start, then. Well ... does auditd provide a record of every command issued within a script? I was under the impression (and I may well be wrong) that it noted only the name of the script being executed. The only things you need to ensure are: - auditd cannot be killed off (this is an interesting bit actually, anyone knows how to do that ?) - the audit trail files can only be appended to ; man chflags An alternative would be lshell, however you'll have to whitelist commands people can execute. Remember that we want admins to be able to do *anything* but we just want to log what they do, in fact do. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
On 12/05/2012 05:44 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk wrote: I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're saying. Are you suggesting that there is a way to configure sudo so that if someone does 'sudo su -' to become an admin, sudo can be made to log every command they execute thereafter? -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
On Wed, Dec 5, 2012 at 3:48 PM, Tim Daneliuk wrote: > On 12/05/2012 05:44 PM, Kurt Buff wrote: >> >> On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk >> wrote: >>> >>> I am working with an institution that today provides limited privilege >>> escalation >>> on their servers via very specific sudo rules. The problem is that the >>> administrators can do 'sudo su -'. >> >> >> >> >> sudo is misconfigured. >> >> man 5 sudoers and man 8 visudo >> >> >> >> Kurt >> > > I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're > saying. Are you suggesting that there is a way to configure > sudo so that if someone does 'sudo su -' to become an admin, > sudo can be made to log every command they execute thereafter? No, I'm saying that sudo should not be configured to allow 'sudo su -'. Since you say that the users are provided "limited privilege escalation on their servers via very specific sudo rules", it seems to me that one of three things is going wrong: o- Something is wrong with the configuration of sudoers if they can su to root when they shouldn't be able to do so o- Someone has misconceived what "limited privilege escalation on their servers via very specific sudo rules" actually means, and deliberately has it configured to allows users to su to root o- The users' accounts are already root equivalent, which, depending on the version and configuration of sudo, might give them the ability to sudo to root regardless of the contents of the sudoers file (see, for instance, the screen in FreeBSD when you perform 'cd /usr/ports/security/sudo' and then 'make config') Kurt ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
On 12/05/2012 06:35 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:48 PM, Tim Daneliuk wrote: On 12/05/2012 05:44 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk wrote: I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're saying. Are you suggesting that there is a way to configure sudo so that if someone does 'sudo su -' to become an admin, sudo can be made to log every command they execute thereafter? No, I'm saying that sudo should not be configured to allow 'sudo su -'. Since you say that the users are provided "limited privilege escalation on their servers via very specific sudo rules", it seems to me that one of three things is going wrong: o- Something is wrong with the configuration of sudoers if they can su to root when they shouldn't be able to do so o- Someone has misconceived what "limited privilege escalation on their servers via very specific sudo rules" actually means, and deliberately has it configured to allows users to su to root o- The users' accounts are already root equivalent, which, depending on the version and configuration of sudo, might give them the ability to sudo to root regardless of the contents of the sudoers file (see, for instance, the screen in FreeBSD when you perform 'cd /usr/ports/security/sudo' and then 'make config') Kurt Oh, OK, I wasn't being clear: - *Some* users are granted the ability to do sudo su - These are the sysadmins. - All other user are given selective ability to run only a few things via sudo. This varies by department and is controlled through a combination of sudo rules and central LDAP group membership control. This is necessary because, for example, some DBAs need this when installing a particular client. -- Tim Daneliuk tun...@tundraware.com PGP Key: http://www.tundraware.com/PGP/ ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
On Wed, Dec 5, 2012 at 5:42 PM, Damien Fleuriot wrote: > > > On 6 Dec 2012, at 00:19, Tim Daneliuk wrote: > > > sudo chown root:wheel my_naughty_script > > sudo chmod 700 my_naughty script > > sudo ./my_naughty_script > > > > The sudo log will note that I ran the script, but not what it did. > > > > > > wow, way to complicate matters. > > sudo csh > > > > > So Gentle Geniuses, is there prior art here that could be applied > > to give me full coverage logging of every action taken by any person or > > thing running with effective or actual root? > > > > P.S. I do not believe > > Now would be a good time to start, then. > > The only things you need to ensure are: > - auditd cannot be killed off (this is an interesting bit actually, anyone > knows how to do that ?) > Can't be done really for an id 0 account. Not without extensive customization anyway. However the Audit Distribution Daemon was recently committed so audit logs could potentially be stored in different location easily. > - the audit trail files can only be appended to ; man chflags Audit Distribution Daemon would alleviate this as well. -- Adam Vande More ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: Somewhat OT: Is Full Command Logging Possible?
--On December 5, 2012 7:01:21 PM -0600 Tim Daneliuk wrote: On 12/05/2012 06:35 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:48 PM, Tim Daneliuk wrote: On 12/05/2012 05:44 PM, Kurt Buff wrote: On Wed, Dec 5, 2012 at 3:19 PM, Tim Daneliuk wrote: I am working with an institution that today provides limited privilege escalation on their servers via very specific sudo rules. The problem is that the administrators can do 'sudo su -'. sudo is misconfigured. man 5 sudoers and man 8 visudo Kurt I'm sorry Kurt, I'm sort of dense today, I'm not sure what you're saying. Are you suggesting that there is a way to configure sudo so that if someone does 'sudo su -' to become an admin, sudo can be made to log every command they execute thereafter? No, I'm saying that sudo should not be configured to allow 'sudo su -'. Since you say that the users are provided "limited privilege escalation on their servers via very specific sudo rules", it seems to me that one of three things is going wrong: o- Something is wrong with the configuration of sudoers if they can su to root when they shouldn't be able to do so o- Someone has misconceived what "limited privilege escalation on their servers via very specific sudo rules" actually means, and deliberately has it configured to allows users to su to root o- The users' accounts are already root equivalent, which, depending on the version and configuration of sudo, might give them the ability to sudo to root regardless of the contents of the sudoers file (see, for instance, the screen in FreeBSD when you perform 'cd /usr/ports/security/sudo' and then 'make config') Kurt Oh, OK, I wasn't being clear: - *Some* users are granted the ability to do sudo su - These are the sysadmins. - All other user are given selective ability to run only a few things via sudo. This varies by department and is controlled through a combination of sudo rules and central LDAP group membership control. This is necessary because, for example, some DBAs need this when installing a particular client. Install security/sudoscript. Paul Schmehl, Senior Infosec Analyst As if it wasn't already obvious, my opinions are my own and not those of my employer. *** "It is as useless to argue with those who have renounced the use of reason as to administer medication to the dead." Thomas Jefferson "There are some ideas so wrong that only a very intelligent person could believe in them." George Orwell ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: grep -Dskip doesn't skip FIFOs
On 2012/12/06 07:07, Marco Steinbach wrote: Hi there, grep(1) does not seem to skip FIFOs when told to. I think you need a patch to fix it, the bug is in ggrep, it tries to open a FIFO before checking if it is a FIFO, then blocked. http://people.freebsd.org/~davidxu/patch/grep.c.diff ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
Re: grep -Dskip doesn't skip FIFOs
On 2012/12/06 11:28, David Xu wrote: On 2012/12/06 07:07, Marco Steinbach wrote: Hi there, grep(1) does not seem to skip FIFOs when told to. I think you need a patch to fix it, the bug is in ggrep, it tries to open a FIFO before checking if it is a FIFO, then blocked. http://people.freebsd.org/~davidxu/patch/grep.c.diff ___ or the patch: http://people.freebsd.org/~davidxu/patch/grep.c.diff2 The patch opens file with O_NONBLOCK, then turns off O_NONBLOCK, and only checks if a file is a FIFO in reset() function. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
netstat -i
Hello, I used netstat -i for the first time and I saw something I cannot understand: # netstat -ibh -I em1 NameMtu Network Address Ipkts Opkts em19000 00:0e:0c:5c:32:29 92M 129M em19000 10.41.170/24 ufo2000 924K 926K I understand that the line reporting MAc address means the traffic seen at layer2, while the line reporting IP address means the traffic seen at layer3. How would that be possible to have suh a difference (on a switched network)? Best regards, Olivier ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to "freebsd-questions-unsubscr...@freebsd.org"
