Re: Security leak: Public disclosure of user data without their consent by installing software via pkg
On Wed, Apr 7, 2021 at 11:37 PM Gordon Tetlow via freebsd-security wrote: > > > Can it be ethically acceptable to put users at risk, for example by > > intentionally (?) not setting any limits to what extent installer > > scripts are allowed to collect sensitive user and system data and > > disclose them to interested third parties? > > This is an interesting point. Unfortunately, the technology we have gives > unfettered access to the system. I'm having a hard time thinking how we could > achieve the goal of installing software (which in our model requires root > privileges) while also limiting what it is allowed to do on said system. I'm > not aware of any other package system (rpm, deb, etc) that has technical > limits on pre/post installation scripts. If you are aware of any examples, > I'd love to see it to see if there is something we can incorporate. Patches, > as always, are welcome to improve the system. For what it's worth, there is some "prior art" in other package management systems for various levels of technical restrictions: * Gentoo's Portage uses a library called "Sandbox"[1], which uses the LD_PRELOAD mechanism to put it self "first in line", and it intercepts various lower level calls that way to mitigate risk. * Exherbo's Exheres packaging format (derived from Gentoo's) has their own sandboxing mechanisms[2] which are pretty broad in scope; I think under the hood it's using sydbox[3], which says it's using ptrace and seccomp to implement it (so it may be more resilient than an LD_PRELOAD approach). * Debian's FakeRoot[4], which seems to use a similar mechanism, but I think this is only applied during the binary package building. LD_PRELOAD based as well * InstallWatch[5] for RPM; seems like this isn't as maintained, so I can't find as many details, but again, I think this is only used during binary package builds That said, I think all these just help protect against accidental missteps, not malicious intent. There's obviously a lot of implicit trust when you're running someone else's software. [1] https://wiki.gentoo.org/wiki/Sandbox_(Portage) [2] https://exherbo.org/docs/eapi/exheres-for-smarties.html#sandboxing [3] https://github.com/sydbox/sydbox-1 [4] https://wiki.debian.org/FakeRoot [5] https://asic-linux.com.mx/~izto/checkinstall/installwatch.html -- Mike Kelly ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Early heads-up: plan to remove local patches for TCP Wrappers support in sshd
security/py-fail2ban in ports is a good alternative. Can be combined with pf and the like to have a similar effect. On Fri, Feb 14, 2020, 3:27 PM Joey Kelly wrote: > On Friday, February 14, 2020 01:18:44 PM Ed Maste wrote: > > Upstream OpenSSH-portable removed libwrap support in version 6.7, > > released in October 2014. We've maintained a patch in our tree to > > restore it, but it causes friction on each OpenSSH update and may > > introduce security vulnerabilities not present upstream. It's (past) > > time to remove it. > > > So color me ignorant, but how does this affect things like DenyHosts? Or > is > there an in-application way to block dictionary attacks? I can't go back > to > having my servers pounded on day and night (and yes, I listed on an > alternative port). > > -- > Joey Kelly > Minister of the Gospel and Linux Consultant > http://joeykelly.net > 504-239-6550 > ___ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org > " > ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: Trying to think out a hack for NSS and pw(8)
You may find that the best way to handle this is to disable enumeration of your LDAP users in NSS. For example, if you're using sssd for your LDAP NSS & PAM provider, it is, in fact, disabled by default. This means that calls to getpwent(3) will only end up enumerating the users in your local files, and not those in LDAP. But, calls to getpwnam(3), getpwuid(3), etc will return the details of a specific username or user id, even if it's only present in LDAP. On Fri, Sep 9, 2016 at 4:11 PM Garrett Wollman <woll...@bimajority.org> wrote: > Presently, we have a bunch of machines under configuration management > (using Puppet, but that's not really relevant here). I'm hoping to > implement LDAP via nsswitch on these machines, but I've run into an > issue: the standard getpw*(3) mechanisms can't tell the difference > between users or groups in the local databases and those in the remote > LDAP database. We need Puppet to manage entries for users and groups > in the local database, without respect to what entries might be > imported from LDAP (because they are supposed to override the data > returned by LDAP). Puppet invokes pw(8) to actually perform the > modifications, but I suspect it also uses native code from the Ruby > standard library to actually do pre-modification lookups. > > Looking at the code in both nss-pam-ldapd and libc, it seems like the > only plausible way to fix this is to add functionality to nsswitch > which would allow it to use different configurations depending on the > identity of the process invoking getpwnam(3) or getgrnam(3). Does > anyone have opinions on how this ought to be implemented, or indeed > how it could be implemented securely? > > (As a side issue, the net/nss-pam-ldapd port completely ignores > account expiration dates. This bug is due to the fact that Linux has > this ships-in-the-night "shadow" mechanism, getspent(3), rather than > having it integrated in getpwent(3) like it should be, but the > ultimate upshot is that if you're using nss-pam-ldapd you can't rely > on shadowExpire attributes in the directory actually have an effect on > FreeBSD. I'll open a bugzilla issue about this.) > > -GAWollman > > ___ > freebsd-security@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-security > To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org > " > -- Mike Kelly ___ freebsd-security@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to "freebsd-security-unsubscr...@freebsd.org"
Re: periodic security run output gives false positives after 1 year
So, can't you just do this? 1) Make it an option. 2) If it isn't set, keep the output like it is now. 3) Set it by default in new installs, with a comment above it that it might break things. That way people upgrading get a warning, too, and can keep it the way it has been if they'd like. On Fri, Feb 17, 2012 at 14:48, Roger Marquis marq...@roble.com wrote: On Fri, 17 Feb 2012, Sergey Kandaurov wrote: Problem with that would be backwards compatibility, and it's not IMO worth breaking everyone's syslog parsing scripts to fix an issue that really isn't due to the date format as much as it is to log rotation. That is not a showstopper. Nothing prevents to merge both formats in one daemon and introduce a new syslogd option to choose the desired format. That would be more of a Linux than BSD way of doing things i.e., deprecating the existing format without giving full consideration to the effects on SA scripts and monitoring software, some of which is hardcoded and difficult to change without breaking more than it fixes. The current syslog syntax timestamp has been reliable now for what, 25+ years? I don't personally see any measurable ROI from changing it. YMMV of course. Roger Marquis ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org -- Mike Kelly ___ freebsd-security@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-security To unsubscribe, send any mail to freebsd-security-unsubscr...@freebsd.org
